How Ethereum Learned to Scale

Transcript

[music] [music] Awesome. Yeah, [snorts] thanks for the great introduction. Hello everyone. Hello everyone watching the stream. Excited to be here. As already said, my name is Tony. I'm with the FRIM Foundation and today I want to talk about a topic that has been my main focus over the last two years and it's scaling. So [snorts] without further ado, let me get into the topic with a quick example.

How scalable is Ethereum today? This already assumes Glumsdam. So Glamster will ship early next year. And with Glamsterdam, we are able to increase the gas limit to 200 million. So we will go from 60 million to 200 million with Glamsterdam. And this will enable us to get like 68 million transactions um per day. This sounds already quite a lot, right? Like 68 million large number. But now if you compare it like to the population of Mumbai for example, which is around 13 million, it doesn't sound that big anymore. And to be transparent here, the 200 million is just a gas limit, right? So to be

realistic, we have to half it because that's how EIP1559 works. So we can actually on average only use half of the gas limit and then the 68 million drop quite rapidly. For example, if we assume now 100 million gas limit, we get to the 30 uh 34 million transactions. Then we are still only doing EH transfers. And Eve transfers are nice, but it's only half of the story, right? There are stable coin transfers, there are privacy apps, there's DeFi, there are NFTTS and so much more. And if we if we now assume a transaction costs 100k gas, then suddenly we are at a point

where only 7.2 million transaction happen. And finally, if we want to have every maker do five transactions per day, then only one out of nine people in this city can actually use Ethereum. And then the chain is full. like the blocks are basically at maximum congestion and the rest of the world cannot even use Ethereum. So this just to set the stage it's very important that we scale the chain because otherwise not everyone will be able to actually profit from all all the nice properties that Ethereum is trying to bring.

[snorts] Before we get into more technical topics like how scaling works and what we are planning to do, let's just define what scaling is because often time it's confused with transactions per second or the gas limit that we have in the blocks. And those measures are like okayish. They're not so bad. But the more precise measurement would be the gas per second or even more precise the useful work we can get per second um of time.

And importantly, it would be very simple like scaling Ethereum would be very simple if we just increase the hardware requirements, right? We double the hardware requirements, everyone buys bigger computers and then we double the gas limit. Like it would be very simple, but that's of course not how Ethereum wants to do it. Hardware [snorts] requirements are increasing though. Like we've seen in the last few years, hardware is improving and we can expect hardware to continue improving. But what I'm trying to say with this slide is there is an increase in hardware requirements but at the same time we will never get to a point where suddenly a full node a validator will need to be in a data center needs GPUs and so on. So it must

always stay um hardware that people can run from their home and this is super important for all the values Ethereum provides especially for decentralization. So let's let's start with where are we today in the last few years we made quite some progress when it comes to scaling. For example with two years ago we shipped EIP4844 introducing blobs and this enabled rollups to post their data on Ethereum and thereby enjoy some of the nice properties that Ethereum has to offer.

And over time with packra fusaka shipping pieras then we did two blob parameter only forks the bposs we were able to get the blob count up to 21 which is quite impressive all unlocked by peer does finally enabling data availability sampling not every node has to um download everything and this was quite a big unlock for the L2s at least on the execution side or on L1, we have been quite weak so far, at least until we got the pump the gas initiative that forced us almost to go from 30 million to 36 million. Like this was almost a

wakeup call for the whole Ethereum um ecosystem to realize, hey, we cannot just ignore the L1. People want to use the L1 and we have to make sure L1 keeps scaling. And that's exactly what we have been focusing on. You can see we went we made a small step from 30 million to 36 million. And this was also the time when clients went crazy into um performance engineering like you saw teams like Nethermind especially but also smaller teams like Ref um or Ephra really going deep into their clients and optimizing the hell out of it. And this allowed us without any additional features to go to 36 million to 45 million and eventually to 60 million.

All a all possible without even shipping a single scaling feature like nothing was really done in the protocol to unlock that 2x already. And this brings me where we are today or hopefully soon. Glamadam because Glamadam has been fully focused on scaling. And I would say there are three parts of glums that will unlock this scaling and it's more time for execution. It's parallelization and also some repricing. So let's get into the first one. EPBS. I think many of you have heard of EPBS EIP 7732. It's a great EIP because what it does it decouples consensus from execution.

There is a beacon block. There is an execution payload. Today they travel together and you have to validate the consensus block and execute your execution payload before you attest. This means you only have 4 seconds for both. So everything was squeezed at the beginning of the slot. With EPBS, this is much nicer now because now we get the consensus block early in the slot. people attest to it and then the payload arrives later in the slot and we have until the end of the slot for execution.

So if we assume we had like two to three seconds for execution before suddenly we get to 6 seconds of execution. So that's basically already a 2x improvement at the minimum for block access lists. It's very similar. We today we already we only execute transactions sequentially like clients have been um doing some optimizations but it has been very difficult to actually come up with a parallelization strategy because transactions can depend on each other with blocks block level access lists this was resolved and finally if you have like eight threats eight cores and 16 threats or I don't know you can actually make use of them

and this also unlocked a lot of scaling headroom that we will then be able to leverage with clums. Finally, there is a uh there is the repricing like one big problem that we have with scaling is that we always have to watch out for every possible worst case. Like there are worst cases when it comes to bandwidth, when it comes to compute and those are even the simple one if you compare them to the worst case of state. State is something super tricky and there are no solutions yet how we actually tackle state. So far for Glumpster we could at least like diffuse the situation a bit because we repriced

state. So state creation with Glamsterdam will become quite significantly more expensive. But at the same time this buys us time to then at the later fork ship something to actually solve state which is something like state expiry or new forms of state. So clamster definitely bought us some time with EIP 8037 80387 very complex EIP. So it's not a it's not a great solution. It's not a silver bullet but at least it will allow us to actually scale for Glamsterdam.

There are also some smaller levers we can still tweak like clients are still optimizing their code bases and at the same time there are a bunch of proposals floating around how we can now go from 200 million to 600 million without too much work. I [snorts] listed some of those proposal up here. For example, we could separate the ball from the payload, giving the block live access lists to the validators early in the slot and just adding another second of useful work for every node. Second, fast payload um propagation like the faster we can get blocks or payloads to validators, the more time they have for execution. So we should really optimize

the networking layer to make sure um we can actually get most out of it. And finally there is three types of new state that we are currently exploring. One of them is UTXO like very similar to Bitcoin but slightly different. We want to create a new type of state that is basically optimized for payments. You can think of it as a specialized payment lane that is very low on state consumption. So every payment will come with only one bit of state and at the same time very cheap to validate. So we will be able to offer like very cheap peer-to-peer payments that are very nice for state growth because they almost

don't grow the state. Second, what I call glacia state very much in the research phase. We could do something like shipping a new op code that allows deafs to now write state into an HDD instead of SSDs. And this is much cheaper. And for some use cases, this might be great. Like you might have state that is not read in every transaction. You might only want to store something on Ethereum. You don't care if it's accessible super fast or not. And for those use cases, we could just say, okay, let devs decide which type of state they want to have nodes to be stored on HDDs versus SSDs. And finally, there is this topic floating

around hot state or some might know it as multiblock warming. There is this concept of warm state, right? Every transaction touches state and then the state becomes warm. Unfortunately, we don't keep it warm over transactions across transactions and we also don't do that across blocks. If we would do that, approximately 20 to 30% additional scaling efficiency because usually most of the state that is needed in one block will be used again in the next block. Like it's actually I think it's like 80 to 90% of the state will be used in most of the blocks. So it would unlock a lot of scalability if we would could if you

could just force clients to keep that state in their caches and then have it accessible super fast. So I would say UTXOs then we have like HDD state and then you can think of like memory state. [snorts] So what's next right? Those are only the small levers we have and the future of scaling I would say looks quite optimistic. First of all, this is like the best solution we have for scaling. It's CKVMs. Like CKVMs is like this magic technology where suddenly not every node needs to execute every block and executing the block is like the heavy burden. But suddenly we have one machine producing a proof, spreading the

proof in the network and then everyone can just verify the proof and verifying the proof is very simple and lightweight. Of course, this requires the prover to be a rather beefy machine, but at least all the full nodes, all the validators will be able to just validate the proof and attest and they have then the guarantee that execution was done correctly. Fi also there is a proposal which is um the partitioned binary tree. today's tree is not so great for many applications. For example, CKVMs have problems with proving um our today's

MPT. Um there are also problems with um things are not nicely separated like if you know how the MPT is structured. There is um we have accounts, accounts have a code hash, the code is again living somewhere completely else, contracts have their own storage and so on. So things are not very nicely separated and with this EAP EIP 8297 we will get partitioned binary trees and one of the goals is to create special types of state within the partitioned binary trees and many of them will help us with scaling again finally and this is one of the most exciting topics in my opinion because

it's like it's like two birds one stone it's PQ and scaling It's EIP 8288. Probably you've heard of it before. So what EIP8288 is doing is I like to think of it as SegWit. Like many of you are familiar with Bitcoin SegWit, but it's like SegWit on steroids because what you can do is we segregate the witnesses from the transactions and we don't stop there, but we can actually aggregate them using Stark aggregation. And this is super powerful because suddenly you can submit a transaction into the mele.

People can take your transaction, aggregate them together with other transactions and then finally there's only one um small proof in the block for all the transactions um that previously carried signatures. They now only carry like small amounts of data attached and suddenly we can um like batch verify them all. So this is definitely an EIP to look out for. I would assume we might ship it with AR like in one or two years, but let's see. But definitely something very exciting because it's also helping with um the PQ transition on the execution layer, [snorts]

right? So on the long when we look at the long run, of course, PQ is like everywhere, right? So PQ will add a lot of um a lot of work for nodes and we will have to deal with that like [snorts] signatures will be um larger the general the networking layer will be stressed a lot and we need eventually to scale because otherwise if transactions cost more gas and become bigger this means also less and less people can use um the chain or [snorts] the chain might become more expensive and this is why scaling NPQ you are actually I would say very complimentary. We need both of them.

Finally, I also want to be transparent about the problems we have. I see there are many young folks in the room that are probably hungry to solve research problems. Look at those free research problems. Like all of them are still hindering us from actually unlocking the full potential of Ethereum. state is very difficult to solve. We need a sustainable solution for state. Second, um the proving requirements are very high. We I think people the CKVM teams are working hard on reducing proving requirements, but they are still quite high today. And finally, as you might have heard with respect to Glamsterdam, repricing is not easy. like we need

repricing but at the same time they affect the application layer and it turns very complex very quickly. So [snorts] those are definitely three things we have to work on and then I'm very bullish on getting to 600 million gas limit 3xing that again maybe in 27 28 and really unlocking the gigas future that we are all dreaming of. Yeah that's all I have. Thank you very much. >> [applause] >> Let's hear it for Tony. Ladies and gentlemen, Ethereum for everyone.

Scaling and PQ. If I have $1 for every time someone says scaling and PQ on this stage, I can retire today. So, ladies and gentlemen, please continue to send in your questions and also if you see a good question, please upvote it. Okay, let's go to the most popular question first up on the screen. Okay, Tony, hardware requirements are just part of the problem. blocks propagation becomes a network problem. How would you like to address this? >> Yeah, I think I mean bandwidth or how much yeah how much bandwidth you have is also part of the hardware here. I definitely agree that um bandwidth is one of the things we we have to look carefully because we have to treat carefully. Um it's not so clear. Um of

course EIP8288 helps a lot like we reduce bandwidth with the same amount of transactions. I'm not sure if I get the first part of the question right. Um that hardware requirements are part of the problem. I guess yes. Like if we have very low hardware requirements, it's we are making our life more difficult when we think about scaling. But at the same time, if we just increase the hardware requirements, which would be easy, then we also lower the number of people that will run nodes. So it's a trade-off in the end.

>> Y >> Yeah. >> Yeah. It's always a trade-off in the end. All right. Next question. Okay. Uh, what would a good verifier only node to full node running L ratio? >> Good question. Yeah, I mean I would I would maximize the number of full nodes. >> Yeah, full stop. >> Maximize the number of full nodes. All right, quick answer. Let's go to the next one. Okay. Are there any proposals to use alternative storage data structures non-treebased but using latis or hash hashbased homorphic commitments?

[snorts] >> Um so far I'm not aware of any like at least we are not looking into any of those topics but would be interesting to connect with the person asked the question to see what's out there. >> Great. Yeah. So don't forget if you asked an interesting question, you want to chat more with the speaker, Tony will be around after the session. So please chat with him now. He wants to get to know you more as well. Cool. Let's go next. With BAL, how big block size comes to be and which parallel execution mechanism is chosen? Just executing each block at once, is there any overhead or tradeoff to do that?

>> [snorts] >> Yeah. So block level access lists will increase the block size because of course they will come together with the execution payload. They're in the same object and you can think of it roughly doubling the size on average. And I want to stress on average because the worst case block size will only slightly increase. >> All right. Thank you. Good answer. Let's go to the next one. We've got a few more and about 2 minutes on the clock. Let's see if we can do all of them. How much do we need L1 to scale versus just using L1 for settlement and do most of the scaling in L2s? I remember this almost exact same question two years ago at DevCon, but how would you like to address it two years today at 2026?

>> Um, yeah, it's a very it's almost a philosophical question. I think we need both, right? I think everyone agrees that L1 can scale, but we will never be able to scale to the point where we can um on board the whole world. And if we take like banking the unbanked seriously, we will have to use L2s for that too because they will unlock like the really the the the big scaling for Ethereum in the end. But at the same time, we also need to scale the L1 because many users want to use the L1. They only trust the L1 and for them I think we should just um also scale the chain.

>> Yeah, exactly. We need both. A little bit of both. Okay, cool. Why not a protocol level mirror node for historical state? Very technical question we have. >> Yeah. Um like this this goes very deep into state expiry. I think state expiry has always been a topic um on people's mind. It's just very difficult to come up with a solution that works. So if there is someone that has the solution ready, please reach out. I'm very interesting to hear about it. >> State will be one of the most important topics for Ethereum in the next few years. Yep. Yep. If anybody has the solution, Tony will be available. Go and talk to him later. All right. Two more questions. Let's see if we can set the

record for finishing all the questions this afternoon. Why does state access have to be protocol level specifications? Why can't we let each client optimize cold or hot state? [snorts] >> The only reason we need to have that specified in protocol is because we price it differently. So hot access costs less than cold access. And if one client has stayed in their memory, the other client doesn't, they still have to charge exactly the same for it. Otherwise, we would run into a chain split.

>> All right. Thank you. Last question, Tony. This one is very philosophical. Beyond the will and interest to work on unsolved problems, there's also the question of how to make a living doing so. It's a practical question. Do you have any recommendations for the audience how you can combine both? >> Yeah. [snorts] >> Yeah, it's a very good question. and a very hard one. I think um crypto is definitely at a point where we are not in a bull market and I can definitely see that people are struggling to stay in the ecosystem. >> Yeah, >> it's of course easier said than done to just say yeah push through it and there will be another bull market where money flows into the ecosystem again.

>> At least that's my hope. But yeah, it's very hard to say. Of course, the FM foundation has protocol fellowship programs. Like that's a good start for young people just getting into core development. Um otherwise um looking out for grants. Yeah. >> Yeah. Or as I always tell my friends, build good products and people will come and use them. Ladies and gentlemen, that concludes our Q&A session. The first speaker today to finish all his questions. Let's give Tony a big round of applause. [music]