Protocol Research Call #2

Transcript

Perfect. Um and on Twitter as well. Perfect. Perfect. Thank you so much. Okay then. Um let me share my screen and we can get started. Do you wait? Sorry. This is This is where I should start. Okay. Can you see my see my screen? Yeah, we can. Perfect. Um yeah, then let's get going. Um hi everyone. Um I'm Ansa um co-hosting these uh research calls u with together with my colleague Barab who um is currently um off for parental leave. And so I'll host today's

call. Um we uh talked about uh different requirements for different types of nodes on on the first research call. And for today's call, we wanted to zoom in on this specific quadrant here uh on our road map. the shortterm um focus uh for the execution layer which is specifically uh about um execution throughput scaling um which specifically also means that some of the other near-term topics for the execution layer will be out of scope for today's call namely um things like the future of UF um if if any um or account abstraction um topics like that will be out of scope

also out of scope uh for this call will the um statelessness. Um the schedule basically we'll have the main call um split into two parts, part one and part two. Um 40 minutes each with hopefully a little bit of time for for discussion and Q&A uh after after each part um and an intro at the beginning from Dunkrat. And then um we had some last minute kind of additions, bonus additions, and to not make the the rest of the call be too squeezed, we we decided to to basically have a bit of an overflow part at the end. So whoever can stay on for for like 10 20 minutes 20 minutes afterwards after the main 90 minutes of the call we'll hear um from from Vitalik and Justin about um the beyond the near-term vision and then um

have have a discussion that that will be kicked off by Micah. Um so that's that's it for the housekeeping. Um just already to to to mention it we'll have the next research call probably on June 4th which will focus most likely on ZK and um statelessness. That's not for today. So with that, uh, let's get going. Um, Dankrat, do you want to start kick us off? Uh, sure. Um, wait, how do I share the screen here?

Let's see. Okay, I can only share the whole one. All right, can you see my screen? Yes. Cool. So, I'll give um a very quick intro on uh why scale DL1. Um I think like I already like tried to summarize uh my my view on this in in the recent post on ETH magistrians. Um but I'll try to like visualize it a bit more here as well. Um so to start with I think um like u most people here are technical and so I think like uh the the most important part of this is like of obviously like um if we could have scaled the L1 10 years ago we would have

done so um but uh this time is different like uh the tech is actually ready or like let's say at least very close to ready so that like on yeah pretty short to medium-term time scales we can um we can expect significant advances in um uh our ability to scale the L1 while remaining verifiable and that's because um ZKVMs with real-time provings are becoming available like within the next few months I say like maybe second half of 2025 and then um also um Ethereum will have data availability sampling soon uh with Pas that's

expected um in the next hard hard fork. So that's um hopefully within 6 months um at most within 12 months. And so this is everything that we need to verify a scaled L1. So like once once we have these um it's basically no longer a concern oh like can everyone actually follow the chain and uh this brings us to like thinking about what um um our node architecture should look like for the 2020s like when Ethium was first designed it was more like an 2000's node architecture and that remained in the 2010s and um that's basically we put everything into this one little stateful node and that

fundamentally limits um our scaling. And um in the future we can get the current and much better properties while even scaling by um spreading out our node form factor and going on the one side to extremely lightweight stateless nodes um that can even run inside user wallets easily. And on the other side, uh we will have a small number of um nodes that are a bit more powerful and um and will be able to prove things or take special um peer-to-peer um roles.

Um and then coming to more of the other side of the why, which is like one is yeah, it's possible, but why should we why should we do it or why do we really need to like make it a big priority? Um one is um if we just think even about the existing rollup ccentric road map um what we want is not the picture on the left where there's like a tiny L1 and then like very big powerful roll-ups and um there will be more on this why this is bad later but like um what we want is this powerful L1 and then many rollups that cluster around it um because like on the left hand side at some point those roll-ups might start thinking okay why am I a roll up here? Why am I not

somewhere else or so? So like basically it's not a very stable equilibrium whereas the right hand side can be much more of a stable equilibrium. Um the other thing is about fee revenue. So like at some point I do believe that Ethereum will have to prove that it can raise a good amount of fee revenue. like it's not this is not about whether Ethereum should be purely valued on that but it just makes Ethereum or Ether the asset strictly bad better if it can uh and it makes it better if it can even if it doesn't. Um so the one thing that we know is like contentious state on an execution layer with DF has an obvious

mode. There's something that you can do on such an execution layer that you just cannot do somewhere else. Like if you want to access the liquidity that's on that layer, you can't go somewhere else and get that same liquidity. It's just not possible. Like for example, if you just want to send money, that's different because if you have money somewhere else, you can send it somewhere else. But like yeah, so one once you have this defile state, it is actually it has a fairly strong mode and data availability at least in its current form does not have this mode. I think we can develop into something that has more of a mode. But like at the moment the way that current rollups work, it has very little of a mode which we can see because people simply like do change data will be sometimes and like

this indicates that it does not have a strong mode. So this means that the fees you can charge for this are tend to be much lower. Like if if you can just go somewhere else then like when the fees get high then you go somewhere else. Um but like uh if if you can't then you will pay the fee. So this this indicates that an execution layer is able to charge higher fees than a datability layer at the moment. And so this quick request, could you minimize the zoom controls under the more menu? We see them and they are covering the slides. I think you can click the more and hide the more with the 17.

I thank you so much. Okay. And so this means that we should aim to have as much of the valuable D5 liquidity on L1 as possible. And like to finish off like this is kind of like an illustration of this like I think like it's also a problem that like people see this often very b in a very binary way like oh data has no mode that's I don't think what anyone is saying the question is like how strong is the mode and I think the way we see it at the moment at least is that an L1 uh or like an execution layer with DeFi

liquidity on it has a much stronger mode than like just providing a data availability layer and so we should uh aim to keep that and to build that and in order to have that we need to scale the L1 sufficiently that D5 can stay there and yeah that's it from me great thanks um then you can end screen sharing um oh I can probably end screen sharing for Okay. Okay. Perfect. Um, thanks. This was more basically meant as as a bit of an intro um talk. Um, and then we get now we go into the individual kind of technical uh presentations.

Um, so here um yeah so so I'll talk a little bit about um this topic of um scaling loops. Um and in particular uh I really want just want to focus on on kind of like one picture here and that is specifically uh Ethereum the execution layer has not um had any ambitions around meaningfully scaling the throughput for a long time. So as this is now changing we have to think about how do we uh deal with bottlenecks as they come up. And the way I basically I want to um to to frame this is is that there's really two parts to it. uh we you you have to identify the the the bottlenecks and you have to address

them. Um identifying is a pretty uniform uh process. Um addressing them we actually have several very distinct um tools in our toolbox and I wanted to take some take a moment to talk about all three of these um that I call improve containment change. Um and specifically let's let's go through these individually. So first on the identify side um people always talk about the gas limit and raising the gas limit. I think as we now start to get serious about doing that we have to actually start being much more precise and high resolution about what that really entails because Ethereum throughput is not just one unified thing. You can just scale up by a factor of 10 by a factor of 100 or something. it it consists of all of these small individual bottlenecks that

you have to basically in a way scale each one by one. Um, and I just wanted to like sketch that out here like this is by no means meant as like a conclusive comprehensive um of the bottlenecks uh that that we have. It's really more like to give you this this idea, right? So basically um on the state on the on the state uh there's state size um just as a how much how much over time have you accumulated but then there's also the the number of reads and then the number of of writes in in a block and these basically do have a subtly uh distinct um um bottlenecks that they that they touch.

So, so state size is is is is relevant for the disk space for nodes, but it also affects the the the reperformance, right? Because usually databases degrade as as this or database performance degrades as the overall size of the of the data increases. Um, it also impacts uh sync um and and and so on. So basically like you you can really look at look at this and again a more mature version of this um is probably like five times as as as comprehensive. Um and and the goal really has to be that you you need to basically address like identify and then address each of these bottlenecks individually. Although of course often you can you can basically get features or or other types of improvements that help with multiple of

them. And and just as a small example um as as we got going recently with the scaling impact the the first bottleneck that actually was identified is this may maybe counterintuitively this um peer-to-peer dos vector that um that directly um is a function of the of the block size. So basically nodes on the network they just don't want to deal with too large messages that PS can send them. Um, and so we really wanted to keep this like 10 megabyte uh limit in terms of like how much an individual how large an individual measures can be and and that's a bottleneck that wasn't all that obvious before people basically started looking into scaling. So so basically by actually um um um getting serious about looking at the individual

bottlenecks um gas limit no longer is the main thing that that we really focus on. So then once we've identified all these individual bottlenecks how can we handle them? um basically once we know how close each of them is to becoming the the main blocker for scaling. Um and here the the categorization that I that I would want to propose is um improve, contain and change. And what do I mean by those? So the first loop and that's why I called it the kind of the scaling loops. The first loop here um is I would call that the engineering loop. So improve just means um ch change the code engineer a client that is more optimized around higher throughput levels to address um the issue. So for example um on on state databases um we've heard

from clients that they were saying well the choice of database was informed by the rough size of today's Ethereum state as we say want to scale that by a factor of 10 they would have to look into uh choosing a different database maybe even designing a new database type um from scratch these kind of things. So these are changes that um require meaningful engineering attention um but they basically do not actually require changes to the protocol itself. Right? So that's the first um um loop and and I would say that's the easiest to get off the ground and that's the one where where I think over the last few months we've already seen the most initial progress um because that loop can mostly happen within the individual client teams.

Then we have the second loop um the contain loop. Uh what what do I mean by that? that's basically supposed to be kind of hot fixes for bottlenecks that we can't immediately remove with engineering improvements. Um, and to to look into that a little bit more, I kind of um created this one slide. Um, so so so what does it mean to actually contain contain a specific type of bottleneck? So as I said before, we we currently one one bottleneck that was identified is kind of the the worst case block size. So what do you do here if you can't just immediately engineer your way out of that problem? So the first thing that you always have to do if you want to to to contain um um an individual bottleneck is you have to meter the

bottleneck in protocol. There's no way around this. That's why I put it at the top. Um no matter how you want to then choose which option you want to choose in terms of containment, you always have to at least meter in protocol. What does that mean? You have to have a way doing block execution or something to basically have a agreed upon value of okay the total block size is this amount or the total compute resources spent is this amount or something you have to track that for that specific bottleneck in protocol otherwise you can't have in protocol rules around that. So that's that's basically step one and then once you have tracked that in protocol meter that in protocol you have three main choices of how how you deal with with with such um uh constraints. The first one is the simplest that's that's a

simple cap and that's what we are looking into right now with with w with with the um the block size. The nice thing with a cap you just say okay a block is invalid if it's larger than this amount. The nice thing it's it's it's really really simple and it is actually relatively um uh it has has this nice consequence that it does not um impact the average throughput of that resource. So today's average blocks are already much lower than um than that 10 megabytes and so even if we scale we would never with average case load hit that throughput. The one downside is and that's already as I'm saying this maybe obvious um these these this kind of capping solution becomes brittle as basically um we have higher consumption

higher natural consumption than the cap would allow. Right? So basically if the if the if the if the demand for that resource um um um goes um um significantly above the cap um a the fee market starts to degrade but but also like block building for example becomes really difficult because you can't naturally order the transactions in in an easy way anymore. Um so it's it's it's a very good kind of choice for a hot fix. Um it's not always the right choice for for every kind of bottleneck. This the second option you would have is to just make the specific thing more expensive. Um so you can basically for example we did this in the past where basically state rights became more expensive or things like that. Um it's also very simple right it's it's a simple change you just basically make that price more expensive. Um it is also

robust at high consumption because you just can't have more than that amount of consumption. So nothing nothing degrades there. The the one big downside there is that you actually decrease the uh the throughput the consum the the available consumption for that resource because you it's it's now more expensive. And then the third third choice that's the researcher's favorite choice that um core devs are always um quite rolling the eyes at. That's basically the idea of multi-dimensional pricing. Um often an overkill um it's it's definitely not not simple. It can be the kind of the um most principal choice because it is nice in the other two dimensions. So it actually increases the the throughput of that resource because now you can consume that resource just in parallel to everything else. You no longer like

have to choose do I consume compute or data or what not. you can choose both of them. You can consume both of them and it is also robusted high throughput but again not simple so more of a um a choice if we can't do the other things. So that's kind of the contain loop. So that basically um that allows us to to to contain things that can't immediately be improved. And then the third one is also obvious um that is actually make protocol changes ship new features to um overall alleviate a bottleneck and get give us higher throughput. Um and of course why would we not always just make changes? Well I mean first of all there's not always changes that can increase the throughput of something.

And the other way um but the other important point is also that these three loops operate at very different timelines. So the inner loop the improve loop can in principle happen very quickly. That's just like a roll out of a new um client release. Of course still needs the work to actually get get to that improvement but once it's there you can immediately ship it. Containments need hard for fogks, but you can add them relatively last minute to a hard and then changes, new features actually require you to rework the the execution layer. And that's of course the by far the most disruptive, by far the slowest. So basically, you try to always stay at the basically quickest feedback loop and only move down as you as you need to.

Um, and then one last point there, maybe some some people here on the call right now might might be from the layer 2 side. Um it's actually interesting to see that the layer 2s have already been able to focus on the innermost loop, right? So they they've already um increased um client performance quite a bit, but because they're trying to to be VM equivalent, um the the outer loop is is not available for them. And that's basically where we on the on the L1 can also help unlock things for them. Um and that's really the message I wanted to kind of have in in this section of the call. Um just uh maybe to explain why why is the call is the rest of the calls um ordered the way it is. I was trying to like roughly orient us um to this kind of identify and then improve

contain change um um uh ordering. So we we'll have Masin next uh talk about um PerfNet a little bit which is the main tool we now use to identify bottlenecks and then we'll talk a little bit Shaba will talk about an example of how engineering improvements can help. We'll talk a bit about containment via in the pricing sections and then the big the big section on on on changes to the protocol. So that's that's that's it from from this and so we can move on now to um Marin and Min do we have slides or screen sharing anything or do you just want Yes, I would like I would like to uh to show my screen.

Okay, perfect. You can share your screen. Uh do you see my screen? Uh so uh I'm Martin Sakra from Nethermite. uh I would like uh to tell about perfet and uh other initiatives related to uh testing performance of ethereum clients. Uh perfet is a dedicated uh network designed to stress test client implementation by pushing uh parameters to the limit. Uh we will run we will run uh plenty of uh perf nets each targeting specific areas like block gas limits lot timings block target and more. Uh our uh

main goal goals are to define realistic achievable and secure limits for Ethereum's near future. Uh we would like to determine how far parameters can be stretched while maintaining network stability. uh we want to understand uh what clients can truly handle uh and find areas uh where implementation can achieve significant gains from small improvements. Uh we want to uh test various state sizes including empty state, current mainet and uh significantly larger than mainet like the next mainet simulated state. Uh first perfet is uh already

running. Uh I pasted a link on the chat where you can find some insights. Uh it it has four giggas gas limit for second slots. It was started with empty state. Uh five execution and five consensus layer clients are included. Uh we already have plenty of findings. Here are two uh examples from Nethermind. We also shared some findings with other client teams but this one from Nethermind are fixed and I feel comfortable with sharing it. I'm not sure about status of other issues. So uh it was just reported to client teams.

Uh you can uh have some insights on Teragas WTF. Uh it's uh actually like a brand brand new never mind UI not released yet uh but uh it will give you some insights into currently running perfet. Uh we are planning to run a second perfet uh with parameters 60 60 million gas limit 12 seconds slot and started from mainet state and goal is to test parameters that that are expected on mainet in the near future.

Uh in parallel to perfet uh we are doing worst case scenario research um analyzing the performance of isolated op codes and pre-ompiles. We want to identify potential bottl bottlenecks and determine the client speed on it on which uh clients are are uh which clients can achieve without complex changes in uh Ethereum protocol. Uh it's built on prior research. Uh I think we don't have uh too much time so I I will skip the details. uh like previous research led to finding numerous uh bugs in E

clients. We identified many performance bottlenecks and uh we found important bottleneck in protocol and uh it resulted with creating the AP with modex gas cost increase uh which is uh which will be included in Fusaka. All findings and conclusions can be found in the report. I pasted it on the chat. We found many vulnerabilities pointed what need to be changed in protocol and uh what client specific things must be changed at gas limit of 30 million. We pointed out what we need to change to to

be able to achieve 50 million uh gas. But in the previous research we ignored state grow and focus only on EVM performance. Right now we want to include analyszis of state and we plan to include additional previously untested op codes and perform deeper analysis of already covered op codes and pre-ompile. Uh we hope to find more sophisticated scenarios and uh and hope to find new bottlenecks and Uh first first st is to review and potentially fix all the skates which we already have and and prepare more. Uh and we are planning to

uh to run it on empty state mainet state and artificially generated state similar to mainet and uh significantly larger than mainet like than x. And at the end you want to compare uh results across all these states and understand the impact of state size and history. Uh and artif artificially generating state if like a a task itself. Uh there is already a great research done by Carlos Teres and we are more than happy to cooperate in this area. uh

uh so at the end uh I would like to say that uh we are planning to run something similar to to hive test which will be uh testing uh uh clients one by one and printing the worst uh performing uh test case or pre-ompile and we will run it this time on recommended hardware similar to recommended hardware for validators like in the previous code stop we were testing on slower machine. Uh in the team there will be uh QI engineers, devops and core developer and we will have guidance and support on the entire mind team and and that's all I wanted to share.

Perfect. Thank you. And yeah, as I said, unfortunately we don't have time for questions after every individual section. We'll we'll have Q&A um in the middle. Um okay, perfect. Then we move on and uh Shaba will talk a little bit about networking engineering uh improvement opportunities uh as an example of this first feedback loop. Shaba. Hi. Uh let me share the screen and okay. Okay. So for those who don't know me uh I'm Chab from the gom team recently joined. Previously I was working on on this research uh in codex

uh as I didn't know your presentation so I uh still on the on the identify side but uh okay so I wanted to speak about uh networking scanning real networking uh finding some of the bottlenecks. So uh yeah just a quick introduction it networking in a nutshell I suppose everyone knows it uh ear networking has uh discovery dial sync meool all these kind of topics then we have se networking which has discovery dial sync uh the broad diffusion and at stationation aggregations and and many other things and between these two we also have the engine API which can be the bottleneck so uh there are lots of things here and uh any one of these could be the bottleneck right plus we have minimum of requirements we We have

uh note heterogenity. We have the number of nodes. So uh it's kind of a large space to to map out. Uh but let's see uh let's try to map it out. So is not discovery the bottleneck. Um we often hear discover is too slow. Uh not finding peers too slowly for this and that use case. Uh we have solutions for this. uh I had a blog post on this uh called clinging data from this network fast uh and it's crawling it in less than 50 seconds finding all the notes.

So what you see that is that uh we can find tens of 10,000 notes in in in very very very low time. So uh discover is definitely not the bottleneck um at the moment is dial the bottleneck. Uh dial is is connecting to peers uh when we are connection oriented uh uh actually and we have this problem uh in the e it's also there in the CL that uh nodes are just simply full they are just not accepting even if we discover them uh then we cannot connect to them. Uh we have solutions to this. Uh it's more around uh having subset inbound outbound peer pools. Uh and then uh we are doing peoping. We are scoring peers. We can

have protected peer pools. What you see there is kind of the current state uh about a state few weeks back uh uh in gas uh how fast you can connect PS and and how we changed it now. So uh now you can actually it's not yet merged uh but soon you will be able to uh to ramp up your peer count much faster than than before. Um yeah so dial is uh a bottleneck uh but we have solutions there. sync um sync is also a bottleneck and and the other thing to uh to realize is that we have two use cases and we typically focus on the first one which is a node which is trying to sync and uh

then we are syncing of sync speed and and so on and so forth but that's not the bottleneck the the bottleneck if there is one is the is the second one which is I call it system sync so if we have kind of a catastrophic events and uh basically all the nodes have to sync like a large portion of the network has to sync from a few nodes uh so if it's if sync is the bottleneck then that's the the the use case we should look at and uh well we don't have a solution I'm working on something which I'm calling small sync so this is basically making sure that syncing nodes are optimally using each other's uh resources in a in a little peer-to-peer fashion uh it's kind of there uh to some extent but it's not facilitated by the current network uh we have elements of

it and and we are working on on this one so I hope sync will not be the bottleneck uh that I can imagine it it is now uh CR block diffusion uh is it the bottleneck uh I don't want to waste too much time on this uh uh in 2023 we were measuring uh block diffusion times uh and we found that two blocks are still diffusing okayish uh but it was not okay smaller ones were diffusing since we had quite some research on this that we have segmentation we have a coding over the segmentation we We have uh uh diffusion over different topics. We have batch publishing. We have push uh uh face transition. We have LLC. So we have a

bunch of techniques there in in this uh which might speed this up. At the stations uh estations can also be the bottleneck right um again we we measured it in 2023 and basically what we have seen that at the stations are propagating really fast in the network. So I I wouldn't expect this to be the bottleneck. Uh maybe time to revisit these measurements. Uh but it was really fast. Uh as you can see on the right side, in 1 second, that's in milliseconds. So in in 1,000 milliseconds, uh everything uh no actually.

Oh yeah, it was slower. Well, then I then I put it actually because that's uh before. So at the stations might be the bottleneck. Actually, I I don't think so. Uh but this is to be visited defensively because uh I just uh looked at this chart long and there is plus plus one more zo there. Uh meool me uh so this is a recent measurement I did uh uh whether we have button x in the meool and what you see here is uh the speed of diffusion of uh individual transmiss transactions in the meool. So uh this is uh what you see there is cut time before

uh the block arrives to us and then when the uh execution node actually seen uh the transaction first time. So there you see one specific transaction uh which we have seen first 12.5 seconds before uh it was included in a block before the block arrived which actually included it in the meool and then you see how many information we got from it from other ER nodes and you see that 2 seconds later basically 85% of the network had that transaction. So information is spreading very fast uh in the in the M poolool. Uh here you see individual uh uh transactions and then we can change a

little bit the view. Uh this is where uh we have a common size line. So uh when we first hear about the transaction in the EL uh we start to map out who we hear from. Uh and then we estimate how much it might be diffused in a me poolool and we see that this is uh transactions are spreading really fast. Even blob transactions are are spreading uh fast big transactions blob transactions we are not speaking of blobs but we we can speak of big transactions uh because from this point of view it's the same uh six blob transactions have uh 700 kilobytes uh and in 2.5 seconds it's kind of spread in the network. So uh is this a bottleneck? Uh well not yet. uh when when we scaling it might become but we

have some measurements on how fast it is and uh kind of that's it uh from me uh the next one will be on on finding and solving bottlenecks uh but I don't know when so I I didn't want to put you on the spot with that I think I was just like trying to roughly you know order them in a way that makes sense for people to follow along but uh I think you as well is actually a perfect in between identify and and and engineer and solve so That was great. Thank you. Um then we'll move on to um the um two talks around pricing. First Aid will briefly kick us off with a few general words and then we have Yas who will talk about the

repricing EIP. Um Shaba, can you end the sharing? Perfect. David, are you here? Yep. Let me present. We can see your screen. You can go ahead. Yeah. So, I wanted to introduce the work we're doing on pricing. Uh we have this uh EVM resource pricing uh working group uh which has been going on since uh January uh mainly led by myself and Asgar. Um and um we've been focusing on kind of two areas. The first one is like

short-term pricing improvements. Um as example like we discussed like um we had Marik from Nethermind present like the report and which then became like the modex gas cost increase. Um we also um had a few session discussing like uh uh repricing efforts and this is then became the EIP that um Yas will present uh right after uh myself. Um and we have a few recent ideas. For example, adding a standard config for gas costs like especially since uh we are and will be starting to do like more performance testing. Uh we feel that uh potentially having the standard config matical

clients with all the gas cost parameters could uh really help with that and also with making changes like easier in the future. And we have other discussions around like uh memory cost pricing etc. just to give you an idea and then the second aspect is um I guess less on the containment side and more on kind of the improvement side like the next session uh which is on like medium-term uh changes right so here is about new mechanism and like research to support them um yeah one example is um uh this EIP that is was already out before uh from Vitalik and Tony about increasing cold data cost that's like introducing like uh some change uh on um uh how we

um uh compute like the cost of different resources in the mechanism itself not just in the parameter um and then we had some research on multi-dimensional gas metering um from Maria Silva like um yeah this started in the call um Maria then got a small grant and uh she will be joining rig uh uh soon as a new member. Um and this also inform like uh some recent um uh work from uh Toma on um uh proving costs. Yeah. So then another area that we're actively exploring is um um around like um uh VM execution versus proving costs like both

like uh uh in general but also related to like how we could change u uh pricing um uh constants or how we would need to change pricing constants to adapt um to the switch like uh from like executioncentric to provercentric. Yeah. So this is just a summary. Um if you are interested I will drop the link to the working group uh in the chat. Um right now is mainly like the core devs plus like other people uh in the ecosystem interested in resource pricing and um yeah um I think this was just like introduction from me. I'll leave the floor to um uh Yask to discuss uh his EIP.

Okay. Thanks. Let me show the screen. Um, great. So, hi, my name is Yatk and uh let me just present you the EIP that we've been working on which is uh general gas uh replacing. So, uh come on here. Uh basically what we propose is uh uh the use of gas cost for all most of the um op codes simple op codes from whatever they have now to one. There are a few exceptions but uh you see the general pattern. we just want to uh reduce the cost of it. uh in most cases this is not elastic reduction of course but if you for example see jump jump I this is uh seems like elastic um I'm

explain it later why it is so but let's uh look at the proposal further on we also propose to change the warm data access uh cost and loto uh from current 100 to to five uh this is because one data access might be looked at as a kind of a cache and uh we proved that EVM clients are actually very good at handling it and it doesn't cost that much. Uh further on we uh uh looked at the memory cost and uh memory cost is usually made of two components the quadratical cost and uh per world

and what we propose is to remove this per world uh element uh and leave only quadratic uh cost for uh safety purposes let's call it that way um now we come to uh question why so these numbers that I showed were not made up. We uh done some research. We took seven popular affiliates, created 50,000 uh uh programs, bite codes and we learn them literally for thousands of hours literally and uh why did we need so many benchmarks to um produce uh charts like uh this? So what

we see here for example is a def op code to run on argon in this case. Um and we can measure how size of arguments uh affects the execution time and we can see the the bigger uh first argument the the longer it takes uh and so on but not that much. So by getting all of the op codes and pre-ompiles together looking at some most expensive edge cases and so on, we can create uh charts like this which uh compile the execution of uh op codes for different uh clients compare

them to the current cascus schedule and by uh running some analysis on the data uh we came up with the numbers that I showed you earlier. Now uh if we uh are to implement this um EIP the first obvious uh impact would be a cheaper transaction uh cost. As we can see here from some examples that we done uh for a typical most popular uh transactions the deduction is not that big. There are some edge cases like for example op uh uh bleach which will be um uh reduced the cost will be reduced

significantly not because we uh like op labs so much it's because the actual computational cost behind the op bridge is uh much lower than we um charge them at the moment. um looking more at the uh impacts of implementing such um an EIP first. Uh by doing it we uh make sure that the cost reflects the two computational complexity and therefore cost uh uh of running those computations on on nodes and we restore a balance between op codes. As I showed you

before, we can prove that jump operation is not not much more computationally complicated than uh push zero for example and uh it should be priced at the same uh uh level. There are some of the side effects let's call it. So uh we keep the storage in that schema. We keep the storage price at the same uh level while uh lowering cost of computations that might uh uh promote in the future uh new contracts that um are heavier on computation in order to save some uh uh state. Um we also run um the next side effect would

be learning the quite significant gas uh change but opens a door for the future gas changes presumably for every uh hard folk and um then this is purely my speculation but uh we can assume that by introducing such EIP clients would have uh would need to have some configurable gas cost uh schema which might find some other usages that we don't foresee now but uh it might be useful for the future.

Um so um yeah that's that somehow concludes uh the EIP. Of course there are lots of details, lots of data if you want to look at the link um somewhere here. Yeah, the project was called gas cost estimator. Um u and yeah, that's it. Thanks. Perfect. Thank you very much. Um those were all great presentations so far. Um as expected, we're a little bit over time so far, but behind time, but um the nice thing is at least now this was the most subdivided part of the call. So from now on, we'll have fewer and and and longer slots. We still have um five minutes for Q&A. So if if there's any

specific questions for any of the speakers so far, anything you'd want to briefly bring up or any comments, now would be the time. Otherwise, we can also immediately jump into the next part. All the better. Then our call will not run over so much. Um, okay. Then let's um actually start the next part on time. Um, so then Franchesco will now talk about uh one of

the new features that that are being heavily discussed right now, which is delayed execution. Franchesco, do you want to get going? Hi. Yeah. Can you see my screen? Um, yes. Let's see if that works. Yes, I can see. Okay. Yeah. Uh, so this is I should say also like the this is joint work with with Tony. Uh, but also like the slides very much were made by by Tony originally and just modified by me. Uh, but I'll be presenting it. Uh, so yeah, I'll be talking about delayed execution.

probably most of you have heard something about it but still like a recap kind of what is the point of it and and then mostly dive into um specific issues and and how we solve them and kind of the approaches that we take. Um so yeah the starting point is is block validation today. It looks more or less like this. At time zero there's a block proposal ideally time four there's an attistation and then uh for like the first time where uh the four choices run after a testing would be the the next um proposer um and in practice like today so the time that's kind of useful today would be the time between t0 and t4 so 4 seconds in practice it it doesn't it's not all kind of filled time we have some part of it that's used for

propagation um not very much not the whole slot and then like a tiny portion that's used for execution. I think on average is around 100 milliseconds but it can be there's some like variance there and there's worst cases there are that are much more than that but yeah more or less your average slot might look something like this. So ideally we uh maybe don't want uh to only take like a tiny portion of the slot for for both of these things. And like specifically for execution um I mentioned 100 milliseconds. This is uh you know less than 100th of the whole slot time. So ideally we really would like average execution be a bit longer than that. And uh yeah, the idea of delayed execution is basically to kind of safely uh allow uh time for this. And so to actually

allow execution to happen after this T4 kind of uh attestation deadline um or I mean destation deadline in general like we could also think of moving this further up the the attestation deadline. um just structure the slot differently. But either way, basically the idea is to not uh constrain execution uh by needing to be uh over uh identation deadline so that we we can uh potentially dedicate more of the time before testing uh only to uh propagation and then time afterwards to execution. Um then how exactly you know uh how long should this bar uh this bar be? It's uh not uh you could say, "Oh, this could go all the way until the uh T12 time. It's just whenever the the next proposer needs to

uh basically have managed computing the the state in practice to to like basically have executed know the state and and be able to start building. Um probably that that's not really uh realistic. You you want like building to start a bit before. Um you probably want to not take the whole time because of syncing concerns. So there there's other considerations but the general idea is just we want to allow for for more time. Um and then yeah another um consideration here is uh if we think uh further to ZKVM world this time can also be used for proving. Um so yeah I think this has been talked about a lot um basically with D execution being a bit of a prerequisite for uh for uh having

ZKVM 101 um whether directly or through native rollups or in in yeah essentially in whichever form. Um and then yeah the question would be okay how can we actually test without executing the block like that seems somewhat unsafe. um in particular like we want to validate a block that requires executing. Um what do we do about that? And there's essentially two like families of approaches. One uh is what I've been calling optimistic testing uh which is basically just saying ignore the problem completely like just pretend it's not a problem. Don't uh actually uh do any uh validation when um before a testing. Um you could even extend this

to to be blocks. just don't check anything. And yeah, if then it turns out that something was invalid, you kind of deal with the consequences in the in the fourth choice. So you could basically just throw out the block, mark it as invalid. And I mean, it's not as simple as that. There's there's other things you you need to do. Um, but yeah, essentially it's it's an approach that that's very much just trying not to deal too much with the with the problem. Uh, and then the other uh approach would be uh static validation. So somehow we want to like massage the the validity rules. um in a way that lets us essentially uh be sure that the block is valid without doing any execution. So like statically being able to to validate the block and uh yeah you could think of these as like

one is a CL approach and brings CL complexity in particular mostly for choice complexity and the other one is mostly of in approach that kind of tweaks a little bit the execution and validation rules uh for for the Y payload and uh we'll mostly focus on on the second one um today at least. So yeah, the starting point um when when thinking about static validation is the the block today and in particular uh the block header and the part that's relevant to us is uh the execution outputs. So these are like the fields in the header that are uh things that you only basically can know after doing execution like can only validate after

doing execution. So the the state route uh the like logs bloom request h ash as of the the last four receipts transaction route is not exactly right like you could actually compute this before execution but it's somehow still it somehow still fits here uh based on what we discussed later or anyway just don't don't worry about it too much. Um and then gas used like you cannot know how much gas uh was used in the in the block if you don't actually do the execution. Um and the the idea is uh of course that if we want to do static validation, the block should not actually be committing to these execution outputs. Like you you can only actually check these know that they're correct um if you actually do the the

execution. And so you cannot know this in advance just by looking at the transactions essentially. And so the the first ingredient u for um introducing static validation would be to uh defer the execution outputs. So basically take the the header just as it was before. Um but now all of those fields they essentially refer would refer to the parent. So instead of having state route we would have three state route. I yeah I decided to call this one or I guess we've decided in the IP as well to call this one pre-state route because that's generally what people have been calling it. Everything else is called parent something which yeah maybe maybe it's a bit confusing but it's all kind of the same. They're all like fields that refer to the to the to the parent essentially.

They're like the post uh or like the execution outputs of the of the parent. So yeah, like parent receipt route would be the um route that you get once you get the receipts from the parent. Um and yeah, same same for everything else. And so in the next block, you could actually then validate the execution outputs of the parent, but in the current block, you just don't have those at all. Um and like or you don't have the the ones for your your own block essentially and uh yeah so once you've done this one question is uh what can still go wrong um how can a block actually turn out to be invalid and essentially I mean there's there's different ways that this

could happen but you can basically boil it down once you look at the things that are actually challenging to deal with you can boil it down to basically two things um at execution time it could be that a transaction is invalid because either the sender is not sufficiently funded uh or the execution exceeds the block gas limit. So um yeah the the first case um it could happen in different ways but the the primary way that's that's sort of um problematic is like an account could be drained. Um, so it could it could look like the sender is funded at the beginning, but then it turns out that that it's not. And this is possible as of uh 7702, but either way, this is a problem that you you still need to somehow deal with.

Um, and then yeah, just execution could exceed the block gas limit. Like if you don't execute, you you don't actually know that um you're you don't know what the gas used is. You don't know that you're actually staying within the constraints. And uh so what we could do uh to uh react to this problem is we could just skip the invalid transaction. So uh all of these problems somehow they're related to like a certain transaction being invalid. Either again just the sender cannot pay or it would go over the gas limit or it could go over the gas limit. And so we could just somehow skip these transactions and only leave the ones that are fine. Um and the the issue is um even if we do skip them, they're still committed to they're still part of the block. um this like uh you

know block hashes still exist in in the chain. Uh people will still keep this block in in the history. Um and there's all this data that is skip transactions that are not actually paying a fee. Uh but they're still part of the the history and everyone has and this is essentially the the free DA problem. Like you could in principle use this in a in a kind of a bit contrived way to construct like a a weird um DA layer that that's very cheap. And there's essentially three tech techniques that we have or at least these are the ones that we've encountered to u do something about 3DA.

One is that you could uh pre-charge either the Coinbase or the proposer basically someone that is like in charge of the of the block um for the inclusion cost of transactions. So like the problem is that you know these transactions are are not paying in case they're invalid. But you could charge the person that's somehow responsible for them being invalid. like if you don't you you charge the Coinbase and the transaction turns out to be invalid, it's their fault. You just don't refund them and there's there's no free in that case. Um so that's that's one approach. That's actually the one that we sort of started with. Um and then you could pre-charge the transaction senders instead of the Coinbase. So you could basically uh do the charging of gas fees and transaction value before the block

instead of before the uh before each transaction which is what happens today. Um and then another thing you could do is you could revert the whole payload if there's some invalidity that that happens in it. So basically you just pretend that the payload had no transactions at all as soon as anything is uh is invalid. This doesn't quite prevent 3DA because again the data is still there like the fundamental problem is still there. It essentially is just a way to uh make it costly um but without actually kind of uh really specifically charge in the exact cost like in one the like the approach one the we really charge the exact cost uh for the for the inclusion of transactions. So like call data uh blob fees and like all these kind of things. Um but in three we we

don't we kind of you know just charge this um um cost of which is basically the opportunity cost of missing the the whole payload if you really want to to use it as a vehicle for uh invalid transactions and uh yeah something that uh so these are some approaches. Um one aspect that's not obvious uh that kind of helps us in uh choosing um which or like um that a bit restricts what we can do uh is actually the interaction with with fossil something that looks completely different uh but turns out to be uh quite related. So if we do on fossil it does impose like a big constraint in how we can think about delayed execution because it adds this post execution

condition that you you need to kind of uh check before attesting to an EL payload. Um so the basically um what you would be doing is uh when you attest you also do some uh IIL inclusion check like basically you have some inclusion list and then you essentially want to check that uh if the block actually satisfied the the inclusion list is what we usually say and what this boils down to is you basically uh take some transactions and then check kind of against the payload uh if they could be appended at the end of it. Um, and if they could have but didn't, then you don't want to test the block because it's sort of failed in this inclusion check. Um, so there's essentially this

like uh append validity check where you want to check like uh the possibility of validly appending something to to a block. And uh yeah this is if you think of how uh execution works today this is something that you cannot actually do statically like you cannot just statically determine if a transaction can be appended to the block because again uh the sender could be drained the block could be full you just don't know u these things in advance and uh yeah so this like static append validity check kind of complicates things um again as I already mentioned like EIP772 kind of contributes to this. Like you could have UAS that are drained uh during execution and there's no way to

statically detect this. Um and yeah, so basically in in isolation if you try to just use uh approach one and three which were the pre-charge coinbase and um the reversible payload and actually even optimistic testing uh it would fail at uh giving us like a way to to do this uh fossil check. So by themselves these approaches are all not compatible with Fossil. And so if we do want compatibility, this kind of already tells us that we should look in in in the in the other approach which was this one uh pre-charging transaction senders.

And uh yeah, what this looks like more or less is uh is this you so today uh during block execution you do this charging of transaction value and max gas fees um in in advance like of each transaction. So you like go through all transactions and you charge the sender the the max possible and then you do a EVM execution and what's missing there is you would also do some some refund at the end. Um and then in uh kind of this world where we've uh you we're doing pre-charging to to enable delayed execution. Um there will be some kind of static validation at the at the very beginning uh before doing any execution.

And this by itself should already tell us that the block is is fully valid. Um then we would do we would charge all of the senders. So this would be sort of the beginning of of the actual execution of the block uh where we actually start making state changes and and then we actually go to the to the transaction execution. Um but here we don't charge centers anymore. Like uh all of these uh transaction values and and max gas fees have already been uh basically dealt with uh and like reserved essentially in advance. Uh but we would still do the refunds just just the same. Um so like from a user perspective there would actually be no no difference. It's it's more of like how the accounting is done in some sense. Um there is like a little um quirk that it it breaks the use case

of funding an account during the block execution. Uh so all the accounts would have to be funded at the beginning of the block execution. They couldn't be funded somewhere in in in the middle. Uh but this as far as we can tell is the only thing that that would break uh for users essentially. Um but yeah, still this is not enough. You you could still have um some some like essentially you could still have uh invalidity that gets introduced um by exceeding the gas limit. So pre-charging senders uh only prevents the the first problem where a transaction is not funded but it doesn't prevent the problem where we just exceed the the the gas limit during execution.

So that's still something that that we need to deal with that by itself this pre-charging sanders just just doesn't um doesn't do anything for whereas the the other approaches could. Um and then the other thing is it actually also doesn't quite uh work with for for fossil because this append check uh requires knowing how much gas is available. So if you basically want to check that you can append the transaction at the end of the block, you would want to know um how much gas uh can this transaction actually fit in in the gas that remains. And you you you couldn't uh know this in um with just with this approach essentially because again this is something you can only

know after executing. And um yeah so before if you remember we had uh gas used also kind of turned into parent gas used as a as a field that's um an execution output. So it's something that it's supposed to be deferred in this delayed execution approaches um because again we don't want to commit to something that we cannot verify uh without doing execution. Um but actually if we could have gas used um in in the header and we could trust that it's correct um then that would solve all of our problems um it would enable us to um going back to to here it could it would enable us to know that execution doesn't exceed the gas limit and it would enable us to know how much gas is available and thus uh fully completing this uh pen

check. Um but I we we we can't really uh have this in a in a um we can't really uh trustlessly uh have this without doing execution. We we can't uh verify this but we we could uh basically combine uh some of the approaches that we have um actually have this gas used um but uh not uh do something if it's incorrect essentially. So we could uh start with this approach too pre-charging senders but then if the gas uh and and have the builder declare this gas use in the header uh but if it turns out that it's incorrect we could revert uh and uh basically make the whole payload uh in no op. Um so this was like approach three but specifically only if

the gas used incorrect because this is the only way that the payload could turn out to be invalid in in this uh kind of approach. And so yeah, what things look like at the end once we combine these two is that the builder declares the gas using the header. Uh if it's wrong, we we revert the whole payload. Um we do all of these like uh same u things that I mentioned before about pre-charging senders. Uh so we we uh charge all of the transaction value and max max gas fees before the the whole block execution. And uh at that point we we already know that the the block is valid. It might turn out that the payload reverts but we we still consider the block valid and we can do this um fossil check. So you can essentially

statically determine uh fossil satisfaction by uh doing this simple check. You can you check that uh transaction gas for for one of these uh inclusion list transactions is uh less than the gas available. So it fits in uh whatever remains. And again you can do this by looking at gas used and kind of trusting that that that it's correct because if not the payload will be anyway empty. Um and then yeah the you you just have to check also um could the sender have been charged uh or pre-charged the uh transaction value plus plus max gas fee. So essentially was the sender sufficiently funded at the beginning of the block. If all of these conditions uh check out then you

know that the transaction could have been appended and you can do your basically uh fossil uh check based on this. So you you decide if the builder actually complied with uh your inclusion list view or not. And uh yeah that that's basically it. I mean there's there's more to say. There's a um I mean you can already see from this there's these two approaches being combined. Um I didn't read what's here but yeah you could combine other approaches. uh in in in uh I mean the same approach with uh the coinbased charging or with optimistic testing.

There's a bunch of other ways that that you could do things and uh in this uh ET research post by Tony we kind of go over uh a lot of the possibilities and their combinations and uh discuss like what are the um basically yeah where things go wrong and like what what characteristics the different solutions have. Um and then yeah just quickly uh here is also a link to the execution specs for this specific last approach that I mentioned which I mostly focus on because it's the one that we feel more strongly about at the moment and also the EIP which uh again is right now uh changed to this uh last approach.

Yeah, that's it. Perfect. Thank you. Thank you. Um yeah and again just for context right like um basically the idea for the call was to um have the first section be a bit more like a rapid fire of all these individual um um topics to give an overview and then have the second half of the call to basically dive into the specific two um main focus areas of the E research over the last few uh months which has been delayed execution and block level access lists. So we have uh a call from Tony coming up in a second on on block level access list. But before that um we wanted to uh also briefly have photos talk about EPBS. Again EPBS is of course already further in in in a different stage no

longer so much focused on research more on the kind of prototyping um side of things. H it also basically it's relevant here to contrast um with delight execution because it also reorders the the what we do in in the slot um and when um point being that for now we just wanted to basically present both of them. Um the research hasn't really um progressed much on basically how these two could be combined or basically what the what the relative trade-offs are. So it's not about comparing them. It's really just about um reminding us that that EPBS is is also like a very relevant um second feature in that design space. Pus, do you want to take take it from here?

Sure. Let me just uh share uh I don't know if you guys are seeing this. You can Yeah. Okay. Good. So, this is going to be very fast. I was told uh to like point what are the scaling features of EPBS. And so, it's going to take just one minute just two slides. Uh first of all what EPBS does it it removes the payload and the block broadcast from the hot path is exactly what Franchesco was proposing. Uh there was this uh moving execution to after a testing. Well we not only would do that but we also would just remove the broadcast altogether. So today instead of like having two seconds from broadcasting the whole thing

payload blobs and blocks make it available and then executing and then attesting you now will just only need to broadcast the consensus block. Then later on after uh the attestation deadline the broadcast of the payload and the blobs would come in. That's it. That's all of the uh scaling properties of EPBS. So that's essentially my whole presentation. uh we move to this setup in which the broadcast happens in two stages. First the consensus block then the payload and the blobs.

Well, so now what is the tradeoff with delayed execution? This achieves delayed execution and this achieves also delayed broadcasting which is the biggest bottleneck which is uh bandwidth. So that's it. That's for scaling. I'll mention a few things about uh the trade-offs. So the the main problem in trying to and and the reason why it's much simpler to implement in some sense than delayed execution is because we don't need to deal with things that might be committed to the state that end up being invalid. We don't need to pre-charge anything. We don't need to like deal with like refunding if there's any refund or anything like this at the cost that if the payload appears and is invalid then we need to deal with

instead of blocks being there or not being there as today in force we need to deal with the consensus block being there with the payload the consensus block being there without the payload that's the new entity the empty slot and neither the consensus nor the payload are there so for choice it's becomes slightly more complicated because it needs to deal with the situation where the consensus block might be there but the payload is not and that change is the essentially the unique change to for choice in the consensus side so what are what is the status of this well as I mentioned we don't need to deal with pre prements or anything this is absolutely trivially composable with fossil the

builder would just like send in the bid a list of um inclusion list that it satisfies in the payload, we just commit to that list on on the consensus block. And later on, if the payload doesn't satisfy the inclusion list, we don't need to care about the fact that we committed anything on the consensus side because we just ditch the payload as invalid because it didn't satisfy the the inclusion list. That's it. No dealing with anything on the execution side. In fact, EPBS is the minimal approach to separating the block, the consensus block from the payload. Uh, it is a step forward. I assume that is necessary because at least myself, I cannot think of any way of implementing any of the things that are in the road

map like APS, execution tickets all of those things that rely on an the centralized a tester set and a centralized builder set not using a mechanism that separates the payload from the block. It only involves changes in the consensus side. Doesn't touch at all the execution engine. It doesn't touch at all the execution layer. You might want to make some changes in the execution engine to help in some things. But in as it is as it stands, EPBS doesn't involve anything from the execution side. That means that it can be tested alone in isolation without any other uh without any other components. and it's already implemented in two uh clients in prism man and in techo

that's it perfect um thank you yeah and again the reason um for why I asked us to to keep this presentation shorter is just that EPBS has been around already for longer so there's less kind of new news on how it works and everything we went through this in the past um I just wanted to make sure people have top of mind that there are now two proposals that both deal with kind of reordering um the slots and I think over the next two months or so the focus will be on working out how do they relate to each other um what are trade-offs how can they maybe be combined uh these kind of topics um but that's out of scope for today's call is really more about um pointing out that they both exist um okay then uh we move on to the second uh

main topic for the kind of the the feature part of the call which is um block level access lists Tony do you want to take us through your slides We can't I couldn't I couldn't find the unmute button already shared. Okay, perfect. We can see your screen. Wonderful. Let me start a slideshow here. Great. Yeah. Hello everyone. My name is Tony.

um researcher with the FM foundation and this talk or this presentation will be about block access lists um EIP 7928 which is a very recent EIP but it has in my opinion great potential to allow us to significantly scale the L1. So we before we get into block access lists let's look how the situation looks today. This is a very simplified um picture here. Um so today for every transaction that we have for every um access for every um call we basically have first some IO going on some discrete for example and then the actual EVM execution of course this is very much simplified right because in

practice clients handle that very differently they load state um um just in time they have preet prefetches um running that already um kind of um figure out which um storage or which state is accessed. But just to set the scene, this is basically how it looks today. And over the duration of a block, we get a picture like the following where for every transaction, we execute them in sequence. Um because transactions are often often times dependent on each other. So transaction two relies on some storage slot that transaction one wrote to. So we cannot really execute transaction two at the

same time with transaction one just because of dependencies. And putting that into a gun chart like I did here, you can see that um this sequence costs us some time in the end because we cannot really parallelize um transactions. So we need to um kind of execute them sequentially um being not very efficient. And where we would want to be at is a situation like the following where assuming we have an infinite number of coursees or as many cores as transactions in the block. Of course that's unrealistic but just as an assumption here then we would basically get a transaction execution time or a block execution time of the execution

time of the heaviest transaction. So we would parallelize transactions and then execute them in parallel. Even better, what we could do is parallelizing um IO and AV EVM execution. So what we get here is an even more efficient um outcome because we can start executing transactions before we have even load uh loaded um stuff from from disk. And in the end um after doing the state lookup async, we just compare values and check if everything is valid.

And this brings me to the to the topic to block level access lists because this is exactly what block level access lists are trying to tackle. So what are block level access lists? Looking at the block how it looks like today. We have our block with coming with a header with transactions withdrawals and simply speaking we would just add a new field there which is called the block access list which is which can be thought of as a as a kind of a cheat sheet for validators to validate faster. So we take builders and we enforce them to make the life of validators a little bit easier. And for that we use exactly those block level access lists that

validators get for blocks. Look at them um figure out what the best parallelization strategies and then execute them. And the simple oneliner here would be that um builders provide mandatory access lists that let val validators verify blocks faster. Right? So now that we kind of have some clearance on the goal and what we're trying to achieve, let's look into the design space. So first of all, um we can differentiate here between what do we want to put into that um access list, right? First of all, um the most straightforward thing would be to put storage locations into

it um storage locations um addresses and um keys basically. Second, we have storage values. So we go one step further and we not only indicate where state is going to be touched but also which value is going to be touched um read or written to and finally status because at the point when we already provide values it might make sense to directly go all in and provide the full state diff. So first of all when it comes to the storage location as already said this is kind of easy and straightforward. We have an address and a storage key. And having those storage locations is already quite nice because what you can do is you can already parallelize IO. If you know what is going to be needed, you

can load that in parallel and then you get already some very good parallelization for average blocks because usually blocks are so transactions in blocks are not that um dependent on each other. only a small fraction of the transactions are really heavily dependent on each other but most of them are not. So for the average case you get some quite nice paralization just by having the storage slots because you already know which transactions to distribute to which core such that they don't um yeah interfere with each other.

Of course you don't get any paralization for worst cases and this is kind of the problem we are we have to tackle here. Right, let's move on to storage values. And here we can differentiate between what type of value do we want. We can distinguish between the pre and the post block value and the pre and the post transaction value where the pre-block value is just the value of a certain storage slot before executing the block and the post value is after executing the whole block. And more interestingly on the right hand side the pre and the post-transaction values those are um I would say more more interesting more useful and because for example the pre-transaction value of a storage slot

would give you the value um right before executing a certain transaction. So not the value before we executed the whole block but right before executing a respective transaction and the post transaction value is just vice versa the value after the transaction. And finally, the last um item I had on my um design space slide was the state diff. And the state diff is kind of simple and very small because we don't need much to be put in there because most of the state can be derived from just looking at the block, just looking at the transactions. But for nonsense, for example, if there is a create or create to deploy, we don't really know that by just looking at the block. Um

and for balances we also don't know if there were balances trained through some sophisticated operation. So um we would need to have a balance delta of all accounts that had if balances changing in that um blocker access list too. So this brings me to the last part kind of what is the best design here. And before we get into the best design, let me give you some some quick facts about um execution and about ongoing research there. So it turns out that when we look at the time we spend on transactions, it looks like execution is not the bottle uh is the bottleneck and it's not IO. Um big shout out to to Gary here at this

point because Gary provided me Gary from Ref from GEF provided me all those figures. So for GE at least 50% of the time on average is spent on AVM execution and only 13% on IO. Um second prefetchers and other um methods that make um transaction execution more efficient. They already do an amazing job especially for the average block that we see in the network. But we cannot really scale because they those prefetches are very um performing worse are performing bad when it comes to worst case blocks. And finally 60 to 80% of transactions are independent. So here you can just distribute them across your course without thinking much about

parallelization. Right? So let's look into the design trade-off. And those two designs are the most um promising one as it turned out during um yeah month-long discussions by now. And they come with so those two designs have the storage location specified. So we have a block access list that specifies the storage location. So the address and the storage key and one of them specifies also the post transaction values of storage slots that were written to and the other one provides all retransaction values no matter if it's a read or a right a write and as you can see initially it looks

like of course when we only compare the transaction the execution time the the kind of design on the right hand side is is better just because it's even faster. We get an execution time that is the maximum of parallel IO and parallel um execution. But the problem here is as soon as we add worst case sizes, we see that um the other design that doesn't get you parallelization between EVM execution and IO, but it gets you this sequence of doing IO and then the full parallel execution. And here we get way smaller worst case sizes. And importantly the 0.9 megabyte that's below the call data limit right and this is in my opinion

something we should really be um yeah careful about. So the the left hand side we are below the call data limit on the right hand side we're above the call limit. So if we would introduce something like um block level access lists with storage locations and the pre-transaction values then we would actually create or yeah we would get to a new worst case block size of 1.51 mil megabyte which is one block um touching doing a lot of slos thereby being allowed to specify a lot of um values in the block level access list. So comparing worst cases, I would say the left hand design is definitely um better. Finally, I put that into this

table here too. And because I haven't really um had time to cover it, but on the very right hand side, you can see um the column with state. And the cool thing here is if we have block level access lists with storage locations and the post transaction values then there is not that much left to get to a full state diff right the only thing that is left is the nonsense and the balances and then we would have a full state diff and it turns out that this might be helpful for syncing especially for the healing phase and snapsync. So blocks uh validators would get blocks that includes the whole state diff which is of course nice if you only want to

maintain certain parts of the block and stuff. You don't need to execute anything. You can maintain the state without any guarantees that it's correct of course but you can maintain the state without um execution right and this brings me to the end of the post. I put some QR codes here with some um further readings um E research post that I posted today the EIP itself and my latest website dependency.pig where you can look into transaction and execution dependencies of Ethereum um as of today.

Perfect. Thank you very much. Thank you Tony. Um yeah perfect. And basically we at the end of the the main kind of section of the call. Um we could can very briefly hold again see if there's any questions or any comments up to this point. Otherwise then I would um hand it off for it off to Vitalik to talk about the longer term view here. Maybe that's best. And then we we have this section. So basically the idea is we're now at the end of the the main 90-minute window. So if you have to hop off that's fine. Uh we'll now move on

from this kind of short-term focus. We talk about more the big bigger picture uh questions and then we'll have a open discussion sections for the for the people that that that are still on the call um at the end that that Micah will kick us off for. So Vitalik, do you want to Oh, sorry. Great. I'm here. Lucas, do you want to say something now? Otherwise we can one one thing to point out that this block level access list is very similar to vertical witness but gives us actually less than vertical witness as far as I understand both. So maybe just switching to vertical and using vertical witnesses might be another alternative to do that.

Yeah. I think my own my own understanding here is that like the maximum version of uh an access list actually gets us like basically the same information, right? And the like this is actually a great segue, right? Because I think it's like the point like I'm here to talk about some of the longer term, right? And uh the way that I think about it is that basically the next four years of uh Ethereum are going to involve a lot of repeating a similar design pattern where that design pattern is basically one actor does some extra computation in order to add some extra helper information and then that helper

information makes life much easier for everyone else. Right? And to me block level access lists are the first step in doing that right and block level access lists like they give you enough information so that you can parallelize verification. Then the next step after that is that you basically yeah take the block level access list and then you add on top stateless witnesses and if you add stateless witnesses on top then uh that lets you verify blocks without having any of the any of the state yourself. Um and then the third step in that same trajectory is the full ZKVM.

And the full ZKVM basically means like one person proves a block and uh then everyone else theoretically doesn't actually need to do any computation at all. Right? And I think like we could definitely have some uh debate on the timing of some of them. Like I know there's some people who are bullish on ZKVMs happening quickly. there's people bullish on statelessness happening quickly and so on. I mean like my personal view is that stateless is coming very significantly before ZKVM makes sense just because like ZK stark technology still relatively has a somewhat higher level of risk especially for us to get comfortable with layer one depending on it. But I think uh like

regardless of the of the details of this right there's this uh like big picture pattern going on which is that we're going from every node in the network repeat doing the same computation to uh basically verify by repeating the first what the thing the first guy did to a model where the first guy does some extra work and in exchange everyone else's verification job gets much easier. And the underlying idea behind all of this, right, is that we're trying to scale Ethereum and we're trying to make Ethereum and Ethereum's guarantees accessible to more people, right? So we're trying to make golf sovereignty,

censorship resistance, verifiability, uh you know, open source, open state, open execution, all of these things accessible to a larger number of people basically because if we don't then uh the that activity will happen on platforms where users are going to get a much a much smaller set of those guarantees. But if we do that naively then it becomes unviable to run a node right and uh we of course really don't want it to become unviable to run a node. And so what what these technologies do is they basically say well instead of having one type of node real like the network is becoming somewhat more heterogeneous and

effectively yeah with a smaller number of helper nodes you're able to massively decrease load for a much much larger number of nodes while um while at the same time the throughput keeps going up right and this is like a very delicate process and I think it's a process that we really do need to handle responsibly and really make sure that you know we understand what we're doing that we understand what we're what we're gaining. We understand what we're losing and also to make sure that we uh don't end up um like giving up things that we don't realize are really valuable and

important until after we lose them, right? because it really is easy to make like short-term compromises that say like oh you know we're going to rely on one node being in a data center and uh in exchange uh and then in exchange like theoretically everyone could verify but what that be what that would then mean is like then the chain stops being able to function uh without data centers right so there's a like it's important to I think you know in parallel to some of these discussions on like tactics also And you know like the short term and how also thinking of some of this like long-term strategy uh strategy figuring out like what actually will the end game of decentralization and

scalability look like and there's a lot of really amazing stuff that we can do right like I think within a couple of years we can get to a world where even nodes that are interacting with the chain uh through um RPC are going to get like basically at least similar levels of uh verifiability and uh not quite the same but uh approaching uh like the the kinds of levels of privacy that you would be able to get if you run um if you run a node yourself but like we have to actually think through some of those things that do those kinds of things and uh like to me the uh long the goal of the long-term Ethereum road map is uh

basically figure out what is the end state of all of these different structures that we really wish to see right like basically approach the problem from the opposite ends right it's like if you know if you imagine you're like in a car and you're going from um like let's say Paris to Berlin you know you want to have like a part of your brain figuring out okay how do I get out of Paris so I get into the highway so then you want to figure have another part starting to run and figure out well what actually is the realistic way to enter Berlin, right? And it's like a kind of similar thing here, right? Look where if we decide on the wrong destination, then know we do risk locking ourselves into into the wrong

thing. We're risking so we can go a life for ourselves at the same time. And so to me, this is uh actually the uh a big part of the value of this longer term effort that Justin's been working on and I'll leave to to Justin toh to talk about as well. Right. But uh in uh you know but but but in general like we're able to I think get something which is much more scalable and at the same time something which is very decentralized very ship resistant also much more simple than today and something that offers stronger guarantees than today.

So maybe I'll leave it to Justin to expand on that a bit. Yeah, sure. I guess simplicity is a good segue. Vitalic, you had this recent post on a lot of the advantages of of simplicity. Um, you know, our values, permissionlessness, robustness, neutrality, um, can really benefit from from from simplicity. Things like, um, having high client diversity, having systems that are simple enough to be formally verified, having 100% uptime, all of these things uh, really benefit from from simplicity. And um I guess another theme of of research recently has been optimality. And when you

combine the two, maybe we have a a a a credible path towards oification through through optimality. Now um I guess the reason why I'm I'm on this goal is because um as some of you know um we've had this naming issue around the the beam trademark. Um, and really what I wanted to make sure happens is that if if we do uh change to something else that it's it's a really strong meme. And one of the things that we realized is that uh there's maybe a bigger renaming opportunity for all of Ethereum as opposed to just the consensus layer. And and basically double down on this idea

of of of simplicity. So we have the the three uh layers or I should say sub layers of the L1, the the CL, the DL and the E. And each of these layers can benefit from a a refactor uh around becoming postquantum secure, for example, for the the CL and the DL, but also around snogification. Um and the meme that we're I guess proposing uh today is a lean Ethereum.

So there would be the lean consensus, the lean data layer and the lean execution uh layer. And um again across all of these layers uh at least for the endgame there would be huge opportunities to to focus on simplicity and and maximum robustness which includes snark friendliness and and postquantum security and being lean uh doesn't mean not being scalable. That's actually the opposite. So there's huge synergies between scaling the L1 and scaling a DA for rollups with being lean. And the basic idea of course is very simple. The validators that run on home internet connections and commodity

hardware just verify snarks and and and verify uh dank sharding samples. so yeah, that's that's the the proposal uh now. And um I guess the the goal of of uh sharing it today is is to do a bit of a of a temperature check. Perfect. Thank you. Um we can talk about this as part of the general discussion in in in just a second. But I think before that we my understanding is Micah wanted to say a few words as like words of caution for the for the scaling effort. Micah are you on?

Uh yeah sure. Can you hear me? Yes. Uh yeah, words of caution is one way to put it. Um the I think what I've I've been talking to a lot of people lately about the situation and just to give a summary for those who uh don't follow me on Twitter, which I'm assuming it's just about everybody here. Um the most of the discussion around scaling talks about um staking nodes and block builders and how can we make them as performant as possible. Um the thing that I see missing in all this conversations discussion of the RPC providers currently RPC providers there's like basically three companies infura alchemy and quick node probably a handful of more smaller ones. Um but it used to be that the RPC server was you as a user. So, as a user, you want to

use Ethereum, you double click the Ethereum executable and it runs in the background on your machine all the time. And when you want to interact with the network, you just talk to your computer and you're on a peer-to-peer network and it's a peer-to-p peer system. Um, we're moving more towards a federated system where the users are talking to one of a handful of service providers who are, you know, writing service and they make their money in one way or another. Um, some make it through, I don't actually know how Infura makes their money. Um, but Click Node, for example, sells our services. The problem with this is that's much less censorship resistant than a peer-to-p peer system. In a peer-to-peer system, as long as you can run the software and find one other person in the network that's going to talk to you, you can participate in the

network. In a federated system, you need to find one of the few people who provides like the RPC nodes that's going to talk to you. And we've already seen that um some of the RPC node providers, the companies that do this um do censor people like actively. Like they censor everyone in Venezuela, everybody in Russia, everybody in Iran. Like if you're in one of those countries, you just can't use Ethereum through those providers. Now, luckily, we haven't run into a problem yet, I think, where every uh centralized provider has censored. And so, we haven't hit this yet. Um but it's not out of their own possibility.

And so as I talk to people about this problem, I've come to realize that I think the core issue which I don't have a solution to is that there's disagreement among the core devs as to whether we should priorit when we have to make a decision. Do we prioritize censorship resistance of the system or do we prioritize scaling of the system and of sometimes you can do both and that's great when we can but oftentimes you have to make a choice between censorship resistance or scaling. sacrifice a little bit of censorship resistance, centralize the system a little bit more and you get a lot more scale out of it. And it's if your goal is to scale the system and reach as many people as possible, then it's an easy choice. You just scale the system and sacrifice a little bit of CR. Um, I

don't think this has always been the case with core devs. I think I mean maybe I'm mis misremembering history, but I think back when I got into Ethereum, the core devs mostly prioritize ownership resistance and that has been shifting like this ethos has been shifting within the core dev community. And this I think is what leads to the disagreement as to whether or not we should even have users be able to run RPC nodes themselves. Like as there are many people who now believe core devs and users alike who think that it is not worth it to have a system where users can actually run their own nodes and have their own data. Um and some other people in the ecosystem of course think the opposite. They think

that users should be able to run a node on their computer and have peer-to-peer access, not have to trust third parties, not have to dox themselves to third parties, not tell other people what they're doing, it's all locally available. So, I I would like to I don't again I don't have a solution to this problem, the ethos misalignment problem. I think until everybody agrees on which one we want to have, do we want to prioritize persistence or do we want to prioritize um scaling? Until there's agreement on that, I think we're constantly going to be butdding heads on what the right solutions for any of these things are. I don't have a solution to this problem.

If anyone does, that'd be great. If someone could figure out how to in a decentralized um development community, how do you align ethos? No idea. U so I think that's basically my pitch. Um happy to talk more about it with anybody anytime. Perfect. Thank you. Yeah. Then um we're basically at the end of all the prepared remarks and um presentations. So now I would open it up for this general discussion either to what Micah just said or general kind of topics that came up on the call. Um and then we can wrap it up in the next 10 minutes or so where people are thinking about what

they want to say and just raise your hand if you want to say something. I can I just want to briefly address some of what what you just said, Micah. I personally think that the it's a false dichotomy between some of like basically the the values of Ethereum and um scaling. I I personally think that at the limit at some point you do run into this trade-off, but we are very very far away from the efficient limit right now on Ethereum. And the challenge right now is much more to just like make things legible because once you make them legible you can track them and you can make sure they are in a healthy range. So for example on censorship resistance I think when we talk about this we mostly talk what we mean is mostly the censorship free inclusion of transactions on Ethereum and there we

have looked into this we've researched this and with solutions like fossil we know that there are ways where we can ensure much better guarantees than we have today while actually being able to have much higher scale and basically rely much less on say every proposer being able to build their own blocks at home right so basically there we can have the both best of both worlds and we got there just by making it legible, making it something we track and we find a solution for and then we were able to find that solution. I think what you're pointing out here is good is saying okay look censorship resistance also means having access to state and as we make it so that not everyone has their own Ethereum um um node locally um um and state and also like the the um simulated

results of of of of um transaction execution right so ETH calls um that's just another thing that like I think it's good to raise so we track it but like treating it a priority as this dichotomy of like we have to choose between that and scale. I I just don't think it's right. I think we can basically we just have to make sure we track it and then I don't think like these things we already have sketches for how how to address them. Um so yeah so so my feeling is in the past we never had the ambition to scale and so we just got all of these things for free with the existing solutions. Now as we want to scale we just have to make sure we work for keeping or even improving these um as we go. But I don't think these that these these things are fundamental

challenges. Um yeah, Vitalik actually I wanted to ask a question to either Mike or whoever else knows like do we know what is the reason why the RPC market has been consolidating so much recently. So I can speak to myself and the other people I know who have been on using users of Ethereum for like five or 10 years who used to run their own nodes on their local hardware and it's always the disk usage. Like everybody I talked to who used to run their own node on their desktop, they got to the point where just it consumed more of their disc and they were like I don't care enough to go buy hardware just so I can participate in Ethereum. Um, just like people rarely go buy hardware so they can torrent or

rarely go buy hardware so they can um watch Netflix, you know, they use whatever they have and they just aren't willing to go to that extra step to go purchase hardware still for it. Even if the hardware is not terribly expensive. Um, it's just that's the step that seems to stop a lot of people is having to go specially build for Ethereum. The other minor one is operations. Um, as someone who ran an Ethereum node on his desktop for a very long time, it is operationally challenging. At least it used to be, I haven't in a while for the disc reason. But, um, that was the other reason that people started to fall off that I noticed um, was that it was just it's kind of a headache back in the day where you know kind of break randomly.

You had to do these upgrades every six months. It wasn't something that you could just double click and ignore. Um, so a counter example of this is IPFS desktop. I installed that on my OS, you know, a year or two ago. It still runs. I never update it. It just works. Um, it doesn't consume I I like when I run into bandwidth problems, it's not because of IPFS. When I run into disk problems, it's not because of IPFS. And I use it regularly. Like it's part of my daily workflow, but it's in the background. It's passive. Um, there's no operational overhead. And there's no extra hardware for it. And this is a peer-to-peer decentralized system um as a kind of comparison for what I think people are willing to run. Now, of course, this is a small sample size. is just people I know who were Ethereum enthusiasts,

let's say, historically. I don't know if that is meaningful in the grand scheme of things. That's obviously a different question. All right. So, one type of consolidation is have people moving from self to providers. The other type of consolidation that you hear about going from 20 providers to having three providers, right? because uh like having different options for providers and geo decentralization of providers feel another one of those things that's uh really important for the class of users that will inevitably exist and

inevitably be large that are not running a node build. I'd also be curious that I've got like you know the market or third party folks didn't know what to look like five years ago versus today and has gotten worse at least three companies and always will be three companies and that's a big concept relying on it so dangerous my semi-educated guess is that um a lot of these providers like Infura provide service for free and it's getting more because the requirements to serve

Ethereum go as they go up that gets more and more expensive to provide for free. Also, applications um I don't if anyone has looked at the network uh tab of your browser when you have unis swap open um applications are not nice to RPC providers at all like unis swap is sending you know a transaction or a request every second to make queries to the RPC backing RPC node like for their swap stuff and those are like you know equivalent of a million gas transactions every second to an RPC node and that's every user that has new swap open the tab on their browser uh doing something and so my partial guess is that there's just no incentive to to do it like most users don't want to pay for it as long as

Infura is providing it for free the same same reason why does no one pay for email services well because you can get it for free for from Google and so one provider provides it for free and then no one can compete with that from a pricing standpoint and so no one joins the market because it's expensive to run these operations and eventually you end up with that one provider providing it for free and they have completely dominated the market share and users no longer have choice. And I don't I don't know if there's a solution to that other than like forcing infur to stop providing free services to everybody, but that also seems bad. Like there's I don't see a clear solution to that problem.

Got it. One other question that comes to mind which is like a bit of a different tangent is I wonder like are there things that we can learn from the open source AI world in like what a realistic but successful and meaningful self-hosting ecosystem would look like and uh like what what things succeed what things fail are the things that we could do to try to like learn from and emulate any successes have happened You worry a little bit.

Sorry. Go ahead and score. No, I just want to say maybe this is a good point where like we do async follow on um just to not keep people for too long right now on the call synchronously. So maybe I would I would just like have one last round of asking whether there were any comments or questions around any other parts of the call. Otherwise, I think it's probably best to wrap up here now and then continue this async. But yeah, then I think it looks like no no further comments because yeah, just because we're already 22 minutes over time and I I had announced a little bit

that that we run over, but I don't want to keep people for too long. So then I think it's best to end here and as I said um preliminary date for the next call will be June 4th and we will likely talk about ZK and statusness. Um details and a more detailed agenda will follow closer to the date as usual. Thank you all and um see you on the next call. Bye-bye. See you. Thank you. Bye. [Music]