Welcome to [Music] Eg. Hi everyone. Oh, it's very hard to see in this room. Um, yeah. So, Starknet just presented how they are planning to scale up on Ethereum and I'm here to present how Ethereum is going to scale to allow Starkness and other rollups uh to indeed on board this 1 billion users.
Um, I'm Julian. I'm a researcher at the EF. Uh I've been mostly focused on economic problems up until now. So working on me and proposed builder separation and topics like these. Uh but now I've switched over to doing uh scaling.
So working on layer 1 skating and scaling the amount of blobs that we can provide. Um I'm not here to talk so much about what I've done myself, but it's more of an overview of what the entire EF research team is doing. Um yeah, to get everyone like a feel of what what we want to achieve. Um so the main two goals are I'm not sure if I'm in front of the slides here. Um the main two goals are 100x the L1 gas limit.
Uh so currently it's at 36 million and we want to do this 100x in four years and we want to go to 128 blobs as the medium-term uh scaling target for the amount of blobs. Uh I'm not sure if everyone is aware but blobs are the the data that Ethereum provides to L2 so that they can post their data. So you can see it as just like extra room for layer 2 specifically. Uh and so providing more blobs means that more layer 2 can settle Ethereum and they can settle more data. Um so to achieve this 100x in four years and getting to the 128 blobs we have a rough for planning in mind uh it starts with Fusaka.
So we had Pekra which is a hard fork that launched last week. Uh so now Fusaka is the next fork. Uh it's it's hoped to yeah it's hoped to schedule around the end of 2025. Uh and the main feature in there is peer data availability sampling or pure DAS. And what that does is it increases the blobs quite big.
Uh so in Petra we went to nine blobs and with pure data database sampling we could hopefully go to 48 blobs uh depending on testing somewhat. The idea here is that these blobs contain a lot of data. That's all the testers need to download. Uh but in this next upgrade with pure data availability sampling we do sampling. So not all the testers download all data.
They only download parts of the data. Meaning that in in address if you only download parts you can download more parts and so we can go to more blobs. Then after Fusata, we have the Lamdam fork and that fork will focus on the sken layer one. So I'll go into a bit of what the updates are that we're expecting here, but we're expecting about a 10x increase in the gas limit. Uh and then post Amsterdam, we'll focus on some more uh data availability sampling improvements and layer 1 improvements.
And so you can see that in pure we go up to 48 blobs. So to go to the 128 targets, we need to 3x. Uh and since we go with the L1 scaling 10x in Lamsterdam, we need to do another 10x after Lamsterdam. So uh just to recap, the core problem with scaling is the following. Basically, a builder builds a block and it sends it to all of the testers or your validator that you might run at home.
The problem with this is that the validator needs to do all of the work that the block builder has done. It needs to re-execute. It needs to store all of the state that's been accessed. It needs to download all of the data. And this this limits how big the block can be because you can imagine that your your home validator can't do that much execution.
It can't store that much data and it can't download that much in a short period of time. And so the key challenge to making bigger blocks um is limiting the amount of work that the testers need to do that that builders have already done basically. And so here we're trying to leverage some sort of asymmetry. Ensure that the builder does some work that the testers don't have to do. This data availability sampling is one example of it where the builder needs to upload all of the data u but the attesters don't have to download all of the data instead they only download parts uh and in aggregates everyone ensures that all of the data is available.
Uh but we're moving this to other factors as well. So for example computation we're trying to move away from the tester storing the states we're trying to move away from the tester so that the testers are left with only focusing on the consensus that they need to achieve instead of doing all of the extra tasks that they're tasked with today. Um yeah so how do we scale these blobs without while keeping solo stakers alive? Well there are three main trends and I'd say it's like efficient resource usage uh levering the asymmetry between builder and the tester uh and reducing the the how much we rely on builders uh for the Ethereum network. So first of all the efficient resource usage.
One of the things that I'm personally working on now is ensuring that we use all of the the resources that Ethereum has uh throughout the slot entirely. So I mentioned that the testers they need to do all of the work that builders have done. Uh but this is mostly in the beginning part of the slot. So the builder sends it block the tester needs to download all of the data and it needs to re-execute the block uh update its storage and everything but it has to do so before it casts its vote and then its votes is processed and you come to consensus. And so that means that in the first part of the slots uh validators are really really uh burdened by the amount of data that they need to download and by the amount of computation that they need to do.
And so we're trying to um make this a bit more asynchronous in that setting. So what we uh an idea here is that we we allow testers to come to uh consensus on data without having to execute it just yet. So this is called delayed execution. And that means that we can do the computation during the entire part of the slot instead of having it very heavily in the beginning. And then the bandwidth part is uh another part that we want to work on.
And uh we want to have that a testers download blobs earlier basically. So um I would say the exact specifics don't matter too much but we want to make sure that basically the bar is is completely flat over the entire slot duration. And so now um it's it's very intense in the four first four seconds of the slots and not so intense in the last eight. And so if we do uh get this um like better spreading out of resources, we could do a 3x in blobs. And so you go from the 48 to the 128 blobs, which is nice.
Uh and we could do about a 10x in in computation uh with the data execution. Um so then there are some other works that we're doing. So we're doing some opco repricing. There was a talk here earlier, I think it was by Jose, who talked about gas units and how operations are priced and how much gas they spend. Uh and we see that now these gasines aren't priced like exactly as we want them to.
So we'll do some ricing here which gets us a little bit of scaling. Um then we have some execution hints and multi-dimensional pricing. I won't go into this for time reasons but we can go into it more uh later. So then the leveraging the asymmetry is the other way how we get the other 10x post lamster. So the the the intuition here is that the builder now creates a proof of the block.
So it doesn't send the block anymore exactly to a testers. It sends it some other way but it makes a proof of it similar to I guess how ZK rollups work. Um and the testers then only verify that this proof is correct. And we see there's a lot of work happening on this now. Uh and so uh today there are ZK provers that are proving Ethereum blocks and they're doing so uh very cheaply for so 11 cents per block for example.
Uh but they're taking a bit too much time for it now. So they're taking about 4 minutes and we need them to go to 12 seconds. But the improvements here are really really fast. Uh so we're hoping to get at least some sort of um tests running at the end of this year and then post Amsterdam go uh fully leverage uh this asymmetry with ZKVMs. Then how we want to reduce our reliance on builders is via inclusion lists.
So if these builders take up larger roles in the ecosystem and they they need to produce bigger blocks, they might expect that this is difficult. Uh and so we don't want them to be like the central source of centralization that can censor any transaction. And so what we do there is uh we allow others so your home stager node for example uh to make a list of transactions that must be included in the block. So all you do is you select some transactions that you see in the mele transaction ABC for example and other people select other transactions. Um and uh these inclusion lists are propagated over the network.
The builder sees them. He must include all transactions. And if the builder doesn't then the testers won't vote for the block. So if the builder doesn't adhere to the inclusion lists and censors transactions, its block won't become canonical. So um by like an evolutionary game theory argument there, builders will be self- selected um to be yeah non-ensoring in that sense.
And then um as a bonus for um some of the the privacy oriented uh people here in the audience um we want to go to a more uh private inclusionist design. And so what we have now is we have an ERP live uh that's that's being implemented uh although it still has to be voted into some fork at some point um for for inclusionists and it allows 16 people uh 16 of these homestakers to make inclusion lists. Uh but today you could you could see like who these people are that make their inclusion list. And so for example if you're including a transaction that might be controversial in the in the jurisdiction where you live you might not want to do that. So one of the things that we're thinking about is making this private and this project is called ZK fossil if you're interested.
So what it does is it leverages a linkable range signature scheme where these 16 people that make their inclusion list uh has some plausible deniability of of which inclusionist they made. So we select a large set of people and a subsets of these are allowed to make their inclusion list. uh but you can never link who made which inclusion list to some person and that gives you some deniability that that you weren't the one who included for example a controversial transaction uh but still allowing you to for example include your own transactions if necessary and so the core property that we're going for here is anonymity upon reveal and so just to reiterate our scaling goals are 100xing the L1 dash limits in four years and going to 128 blobs um and something that I'm personally quite in favor of but that's more speculative uh and still still needs to be discussed I guess is doing this via a smooth scaling curve. So if you're an application and you're considering where to launch it might be difficult uh to rely on like hard fork timelines that that aren't set in stone. So Dankad proposed this ERP uh that's that's a more smooth scale and so it says today we're at 36 million gas and in four years we want to go to 100x and he says that as every epoch um there's some increase in gas so that you as an application developer know okay if I launch in a year uh this is the amount of gas that's available and if my application does very well then Ethereum L1 scales with me uh at this cadence right so that's all I had uh so if you have any questions I'd love to take [Applause] Perfect.
Thanks Julian. So question time. We do have time for probably one or two questions. Perfect. So post Amsterdam let's say we enable CK to you know make the all the related stuff much more faster.
Then how much do we trust CKVMs in terms of having or not having soundness bugs or etc. Is there any fallback for that? Yeah. So does that does this work? Yeah.
Um so the current strategy is relying on diversity. So what we could do is that we require the builder to make proofs in for example three or let's say whatever number of ZKVMs. Uh and so it's it's a classic like security um livveness trade-off. You need to make proofs in a lot of ZKVMs assuming that the buds are somewhat uncorrelated. You'd expect security.
Uh but yeah then you have the livveness trade-off relying on multiple ZKVMs. Cool. We probably have time for one more question if anyone has any questions. Oh, okay. Thank you so much, Julian.
Um, you'll hopefully you'll be roaming around for the day, so
Automatic transcript — names and jargon may be misspelled.
