RollCall #12

Transcript

And we are live. Let's go. Great. Thank you. Uh hello. Welcome everyone to roll call poll number 12. That's issue 1461 in the Ethereum/PM repo. Link in the chat. Yeah. So, uh, first topic of the day is something we touched on a little bit last time, but just to rephrase because this has come up again on multiple ACDs. Um, and that's the idea of having a uh limit on the number of blobs that a single transaction can carry.

Have some more sensible boundaries on the uh uh the mele and just generally how things propagate. And so um it makes it a little bit easier to uh reason about and so this is very helpful for the L1 core dev. So last time there weren't any objections raised for this um but as this is now likely to be done on the L1 I think is what just be raising. Does anyone have any objections to seeing something like this happen? No objections. I am curious what the limit will be cuz we you know arbitrum we currently limit oursel to three blobs per transaction need to be done something that strips off. So I think

the ex the exact limit is uh still you don't have any objections like under discussion. Uh there was some some people arguing for seven. Um I think yeah I it would be nice if it's a number that's easier to pack into. Um into the block uh into the the the target and max. Um but yeah I I don't foresee three being an issue for now. Yeah, sounds good. Yeah, we do that because max number of blobs minus the target number of blobs is three. And so that way you were not jacking up the price. Uh I see. I see.

Yeah. Okay. Yeah. I think I think basically like right now probably seven is just in discussion because I think that's the together with the transaction object itself that's like a 1 megabyte below 1 megabyte kind of object. So that's nice for the meool. Um otherwise we you know eight is just like kind of a nice round number. nine would be the the current maximum in in um after pectra. So those are I think reasonable candidates. I think the overall idea would be to just set the limit for now anyway just just so we have a limit to reason about as we go to hopefully much larger total numbers in in in Fusaka um and then adjust later on. So basically if we start with a say I know seven or something and then it turns out that

that's actually quite constraining for several else then we would just in the in the hard fork afterwards in in Glam Sadam next year we would then just raise that and these these are not like permanent locked in decisions just something to to get going. Yep. Okay. Great. Um next uh topic of discussion is I'm going to talk uh some of the things happening um with respect to the EVM on the 01 and uh some of the research calls that have been happening as well.

Yeah. So I just wanted to let me maybe share my screen share um entire screen share. Can you see my screen? Uh that's obviously this is a very empty slide that was just I just wanted to basically briefly just make sure that in terms of ACD recap is mentioned. So obviously since the last roll call the pack on Ethereum L1 has shipped. The main one aspect that in which this uh does affect L2s or at least indirectly is that the L1 EVM now has support for EIP772 which um is this is basically allows delegation for EAS. So, UAS basically can can act as smart accounts.

Um, that has seen quite meaningful uptake already um with most major EUA wallets like MetaMask already having support for this which means that over time users will start expecting support for this and then of course it would be nice if if if if they also have support for this on the L2 side. So uh just saying that I think uh as this is now live on L1 um this should probably at least be like as an L2 you should have a strategy around this and if if the strategy for some reason is that you specifically do not want to support this that's also fine but like I think just heads up you should you should make sure you have a strategy for this in place not sure if there's any anything anyone would want to talk about on this topic

specifically. Okay. Um yeah, otherwise um always feel free. It happens to be that like I'm one of the co-authors of the AP. I also think we have met on the call who is um another one of the co-authors and the main champion of the AP. Um so yeah, I think if if if if that you have questions or something, I think we we could we'd be happy to to answer them. And then just another quick slide before I go into the the research side like yeah Fusaka K already mentioned the request for feedback other thing just to briefly mention uh for Fusaka coming up uh scope wise obviously there was this big change the UF was removed from from

the scope so uh it's for now unclear if and when UF will come to Ethereum mainet which does mean that like again if you have if you have a strategy around UF for your own L2 uh Please be advised that changed on L1. So take that into account. Um Pas will continue to be in Fuzaka. It's the main feature for Fuzaka. So so the blob throughput will increase. The exact numbers are still CBD and depend on how quickly we can get to stability at different throughput levels there. Um it will be a significant change over um the nine maximum and six six target that we have today. Um but the exact numbers we yeah are to be determined. And then there will be some small EVM changes

where again um kind of if you're EVM equivalent um yeah just heads up there um some repricing around MODX and then also at least proposed there are some small individual changes now to basically replace the bigger changes of UF with some more targeted um smaller changes. Yeah. So just that and then the the main thing I wanted to briefly talk about or to talk about is um we had the protocol research call number two and these are basically like calls where we just talk about the future of the Ethereum L1 network um just just um last week um on Wednesday and there was a topic that I think I wanted to briefly summarize and because I think that's kind of relevant for for the EV topic of

EVM equivalents in general um and that was so basically like the call last week was specifically on the kind this this quadrant of the Ethereum road map. That's like the short-term execution layer focused um changes. Um so so basically like where we we're now for the first time in basically 5 years again trying to uh increase throughput which we just have not done uh since since since since before the merch basically um and on this topic uh one one one aspect is specifically as we get going I think it's good to um to talk a little about how we are approaching the topic because that has implications on future EVM changes but also just like general changes and and and how they might be relevant for the L2s as well um and specifically speifically like I I I

gave this brief talk about scaling loops. I'll give a shortened version of this now or just like talk about the L2 relevant aspects there. So I think the way at least I think about this on from the L1 side is that we we will have we starting to build this loop uh in terms of um identifying the individual bottlenecks that keep us from scaling throughput and then having three different ways of addressing them. Um and so basically three different feedback loops. The first one is improve meaning just like in like on the engineering side on the client side basically like remove the bottlenecks by just um things like changing the database or things like that right basically where you actually it's an engineering uh way of addressing the the bottleneck. The

second one is contain um basically just like make it so that that bottleneck does not hold back the scaling of the overall chain and the third one is actual protocol changes. Um so in terms of uh in terms of identify like the the individual bottlenecks that there are like we I think we are getting more sophisticated on this on the one side now there's different dimensions right like different types of bottlenecks that you have uh this is more an example this is by no way means uh comprehensive or even the right necessarily um structuring or something but this this is just supposed to give you like a bit of an impression of like how we think about how we approach identifying scaling bottlenecks um and of By the way, I'm talking about this now. Most of you from the L2 side will have already

much more sophisticated thoughts on this. Like for you all, this might even look a bit naive because you've been having to face the kind of the challenge of of of scaling for for a long time now. So we as we are ramping up, I still think it's good to like sync on how we how we think about these things. So that's kind of how how we approach the kind of the individual um like just like thinking about types of bottlenecks that they are. Um and then in terms of what basically as as we understand which of them are are holding a spec from from from getting to higher throughput. So for example right now on the on the Ethereum L1 there's just like concerns around the the worst case size of of of blocks and there's some some kind of um um constants where basically just if that

size becomes larger than 10 megabytes um the the P2P has some issues dealing with this. So so that's just like a short-term bottleneck. And then how how do we address these bottlenecks on from the L1 point of view? Um as I said improve contain change. Uh the interesting thing is that naturally the only of the three tools that is available for L2s as they want to scale or have been scaling in the past is the improve side and because improve really just um means um not just it's actually quite quite the challenge of course but like means uh engineering uh improvements um and and that does not specifically if you you can remain EVM equivalent even as you change the uh make make changes on the engineering

side um of Um the second one um contain contain is interesting because contain means like sometimes when you identify a worst case bottleneck so for example ZK EVM's face that often right so basically like you have a just like you have a bottleneck with like say catch or something right now you could change it by actually making a change like the last point the change to the protocol rules but then you're no longer EVM equivalent and that is often a tricky thing to kind of like get right so often what you want to do is you just want to accept that bottleneck but just contain it so it doesn't this doesn't block you from overall having a higher throughput level. Um the L2s have one tool that we like us as L2s have one tool that we don't have which is the sequencer. So often what happens is just that the

sequencer just has a limit on how many transactions of a certain type get included in into a block and that's something that because we have fully permissionless sequencing permissionless block building on the L1 side we can't do on the L1 side. Um so that's one tool you have that we don't have. Um um so basically how we think about contain is um is through in protocol changes which of course is harder for you to do as you stay EVM equivalent. Um but the nice thing is as we basically now have to double down on this and become much more pro proficient in in in in regularly doing these things. I think we'll do we'll build up a lot of like more generalized tooling around this which

then hopefully can also be used specifically on the L2 side for addressing L2 specific bottlenecks. Um so basically the three types of containment that that at least I saw in in in preparing this talk was just like you can you can cap a certain type of activity. So just you just only allow this amount of catchex per block or something or you only allow 10 megabyte block size or some something like this. Just basically put a cap on and just consider everything invalid that that goes above that that block. You still need to importantly like in order to to contain any dimension you you have to actually do metering in protocol. You can't have a rule that makes a block invalid over 10 megabytes if you don't have the size as a parameter to be like a available parameter in the first place. Um so you basically you do have

to do to to to basically always add metering in protocol for any type of bottleneck that you want to cap to to to contain. And then yeah capping basically is a very simple thing to do. It does not affect the the average K3 throughput, but it is it does have this um this problem that it's not um robust at at high consumption, meaning that like if the cap actually starts to to eat into what the natural demand level would be, it like has these problematic side effects. Um repric you can just make the thing more expensive. Uh again, simple to do reduces the throughput of course, but is is a robust thing to do.

This is another thing where like right now we we we have been hearing from from alus sometimes that basically they would ideally want to have a different pricing level for several things. So like again think of making ketch more expensive for example or just make several compute operations that are just really expensive for example to prove for zkms more expensive right now that's just very hard to do as part of probably like us needing to do this as well on the L1. You can expect that in the future we will probably make pricing levels more of a dynamic parameter that you can just like change with a configuration file or something which would make it much easier to um to have different pricing schedules on L2s versus the L1. Um and then the the the the last one would be

like some more like some more heavy-handed um multi-dimensional kind uh dimen uh uh new dimension which we did once on the L1 for for blob uh prices of course um and we know that there's interest on the L2 to potentially do this as well. We we had one breakout session on roll call um that's of course um the conceptually the cleanest solution but it is um complex. So, but as we kind of ramp up tooling around this as well on the L1, hopefully that also helps us for kind of delivering these L2 specific derata there. Um, so that's kind of the contain. And then the last thing just briefly, the last part of the of the loop, the the change um I don't think I had another slide on this, right? Yeah, that was the last slide. So basically

just changes as well where like um that just often when we talk to tools again with EVM equivalents there's just sometimes things like new features that would help with throughput that just you can't add because you you that would break compatibility with the L1. But now as we also like change the L1 to be more um uh basically to to allow for these for these features that that that improve the bottlenecks that should hopefully also give you benefits on the L2 because you get that for free. Um, so yeah, I think basically just like I think it's just like as a general topic something where you should you should be aware that that's now now something that's changing about how the L1 relates to the L2s because that was just like that entire kind of topic of the execution layer was something that was

just more or less oified rigid on the L1 and basically so you were on your own. Um, and now as the L1 itself also scales, I think you should like have a like have a have some sort of strategy understanding of to what extent that's maybe something you'd want to collaborate with or just take as an input, but be aware that that's now something that's mutable under the hood basically um, and do your own scaling on top, but basically just something that it's a significant change to how the L1 operates that you should be aware of. So yeah, that that's kind of what I wanted to I hope that was somewhat useful and like happy to also like of course talk a little about if if there's feedback or something on the on this point, but um yeah, that would be it for me. Um yeah uh if wait I don't have a

list of people raising hands. Um Ty, hi. Yeah. Uh first of all we'd be very we uh we offchain labs are also looking into how we can make pricing a more dynamic uh thing and uh what what it should look like and we are working in some uh uh I think interesting directions and would be really really interested to you know collaborate to know where the L1 go is going and uh how we can uh uh uh use uh uh those mechanisms. I think it's a very positive direction.

uh more generally I've been following some conversations in uh the L1 and one thing that worries me in their look in in the L1 look at scaling is that it seems like L1 only cares about scaling um uh prover nodes like we'll solve uh uh staking by with uh some sort of uh uh proposer builder separation. And now what we want and after that what we want to do is make sure that the builder can be uh

scaled and that's like the the limit that we really care about. And it seems like from my experience is that the actual nodes that are important are nodes that don't care about that don't try to prove the network that don't try to stake on the network. Uh that what they do is execute the network and they execute the entire network. They do it just to keep up. They do it to answer RPCs. They do it to trace. they do uh uh uh if calls like for every uh even us offchain labs ourselves we run one node that really

needs to be able to uh we have let's say we have three prover nodes that we run to debug in multiple uh ways and many more than that executor nodes right RPC nodes and infura has RPC nodes And like most of the nodes on the chain and most of the question of h what what scaling is and what are the requirements is for executing nodes is for nodes that will do RPC calls and ETH calls and and things like that. And that's the thing that worries me when I look at where the L1 is going. Uh I'd be happy to hear

more from other L2s here and from other people uh in the direction because like I feel that either I'm missing something very basic or or someone else is. Yeah, this is great like a great comment. And by the way, this this makes me think that maybe what we should do is at some point um maybe next month or something have a um like a roll call breakout where we just try to like bring the people on the from the one side that think about scaling now and the people from the L2 the side that have been thinking about this for quite a while together, right? And like discuss these things. I think that would probably be productive. Obviously I'm only I mean I am now involved with the scaling effort from the L1 but like there are many more people and so I can only talk about some

aspects of this and I think it would be and and similarly I assume like many people from the L2 side that think about this are not on the call here right now. So I think that would probably be very productive thing to do in terms of what you specifically talked about. Um I think this is right. We actually like it's interesting we had on the research call we had Micah um towards the end kind of like have a bit of a discussion session lead a discussion session where he was pointing out that RPC nodes are like a very very important consumer of the chain that um needs to be more front and center in in our kind of um considerations around um minimum requirements and um the load and and basically how we how we basically um do scaling.

Um I think from the L1 side at least how we think about this is that we have this hardware minimum requirements envelope that we recently formalized. There's now an Meta EIP. I forget the number but you can find it if you search for this um where we basically lay out an Ethereum node um needs to have at least this this hardware um uh this and this hardware like the RAM CPU um disk and whatnot. Um and the the the intention here would be to like for now at least scale while staying in that envelope. So we already like by by formalizing this a couple months ago, we already like put it at a level that's maybe somewhat higher than

it used to be informally understood to be. So so we already gave ourselves a little bit more breathing room, but other than that, we expect to basically like we are focused on just like getting more um more of a headroom here for for for for increased throughput, not not by just making it harder to run a node. Um and yes, that the exception there is like block building. So we might uh be more more okay with leaning into features that make block building more complex. But then that would have the nice effect that like a normal following nodes whether that is a node for staking or just for um RPCs for for e like for for basically um tracing for for any kind of more just executing and

consuming the chain. Um the idea would be that those requirements should not change whatsoever. Now, of course, that for example, right now that um that hardware like envelope says that you you need to like have at least I think 4 terabytes of of of NVME um SSDs and so whereas we mostly like the state size right now is a fraction of that and then there's history and we we're trying to like ship history expiry where the history goes away but that means that like state might grow quite a bit and so that will impact performance of IPC nodes and whatnot. So, so this is something we we actively monitoring, but in principle, we're trying to like basically stay within the same pre-communicated hardware envelope for now. And if that ever were to change, we

would like be careful about changing that. I'm not sure that does that answer that question or like answer that comment at all or like uh it does but like yeah the the thing that I think I'm worried to keep in mind is because like a large part is saying that staker nodes will not need especially I think when looking at the uh u further down the line uh plans right for zk proven ethereum In ZK proven Ethereum staker nodes will not have to execute blocks at all ju just for staking and and and

that's and that's good and fine. I think that even then nodes that do have to execute the blockchain are very important. Sorry, I was muted. Yeah, I I agree. And um actually I think I think the the meta this kind of this like hardware requirements EIP actually has a different category for stakers and just like just full nodes. And the idea is that like the the requirements for full nodes should always be at or above or at or below the ones for for stakers, right? And so um now of course in principle you can also have a full node

that just consumes a zkm proof and so it doesn't execute but then for some use cases you do need to execute as you said right right so like I think this kind of this level of resolution of just like just distinguishing between full nodes and staking nodes that's fine for now but for the future we have to become more sophisticated in stateless nodes stateful nodes nodes that have to execute the nodes that don't have to execute then there's also not having to execute but wanting to have the state if for some type use cases that's enough right so if you if you only need say the logs and the statives but you don't actually need to execute or you only need to execute individual transactions or something may for some use cases that's enough for some it for some it's not so I think I don't really have much

like this is not something where we have results yet to or like we don't have a strategy for this yet it's other than just acknowledging that we are aware that we need a strategy there we can't just like scale and just accept that execution now no longer is possible on any reasonable hardware that that's not that's not how we would approach this. But yeah, it is a generally hard getting more sophisticated there um is something we have to we still we're still in the in the process of figuring out how to think about this. I guess is is the point and and again I think we have a lot there to learn from L2s as you all have already like dealt with higher throughput levels and with all of these questions and so I think my point here is I think by default a lot of the L1

people are more like focused on the L1 and the L2 people are focused on the L2 and I think this is really a topic where we would really benefit a lot from bridging this between the L1 and the L2. Absolutely. I I I'm really trying to keep up with what's happening in the L1, but I think that a dedicated forum or something would be, you know, anything uh uh that like uh uh u yeah arranges uh uh communication around that topic will be very very uh uh good.

Yeah. No, that's really good feedback and I think they just Yeah. What I would say is just like give us a little bit more time to like actually have a strategy from there at one point. So, and then I think then like right now it's still very much in the exploratory phase. Um talking there already of course makes sense but I think a little bit later this year I think will be the moment in time when it really makes sense to formally kick off some collaboration effort on this. Yeah. But yeah, good point. any any other just touching quickly on the um RPC requirements. I mean right now it's kind of rate limited or constrained by full

mode requirements and so we don't really need a separate specification for now and I think we definitely would have and would need if we switched over to the VK side of things. We're also looking at like standardizing uh what we expect hardware to look like um as like another dimension that's useful to be able to to talk about and reading about. Um so yeah there's there's lots of obviousation across entire section that needs to happen. Yeah.

Great. Um yeah any anyone else that had any any any thoughts that come to mind on this topic or anything? I think we already I think it's it's it's clear that this is not a onetime topic to bring up once. I think this will this will become something to focus on in the future. But yeah, then that's all for me for everything for now just because I think I just wanted to get the conversation started a little bit. Great. Thanks, Oscar. Uh that brings us on to general discussion. Does anyone have any topics they would like to raise or discuss?

Okay, I'm going to take that as a note. Um, then yeah, thank you everyone for attending. Um, and uh, yeah, we'll chat async. Thank you. All right. Thank you guys. Thank you everyone. Thanks everyone. Thank you. Thank you.