RollCall #9

Transcript

well welcome everyone to wall call number nine that is issue 1172 in the ethereum PM repo I dropped in the chat the agenda in the chat for those who would like uh so we going to start with some things that relate to the L1 and the ACD process where we need some feedback the L1 needs some feedback um so yeah I'll click it over to onar for that yeah hey everyone um just wanted to briefly put on a slide like it's always nice to to to see these things written down um yeah so we've had the last roll

call two months ago so there's been quite a bit of ACD activity in the meantime um of course there was also Defcon so so so a little bit um less than usual but still uh the main update here is that the uh upcoming Petra hard for now has basically finalized scope and the basically is the the second bullet point here so I'll come back to that but but uh last update I gave there was still some some questions um and in particular um the the the two I put on here one was already locked in last time 7 72 I put it on here one more time because it is an action item that I I just want to make sure l2s are aware of that this will change very significantly how EA works and so um given that that's now fully logged in for for pectra um

just to make sure that you have a strategy around that whether you want to support it as well on what timeline and the implications for 437 Readiness as well but then the more kind of the the the new update that that changed since last time is that uh we indeed on the L1 decided to increase the um blob throughput which um given that most most of you all are basically consumers of the of the of of blobs and that that hopefully is is good news um and in particular we went from today's uh situation where we have um in average like a target throughput of three blobs per block and and a maximum of six we will we will go to six n and given that the throughput is a function of the of the of the Target that that equals a

doubling of the of the throughput um so so we'll have twice as many um plops and of course the the the the longer term Vision here is that in the next hard fog fusaka we will chip pias so we will move to a sampling based data availability checks which is much more efficient and so we will get like a larger scale increases and throughput there but the doubling in the meantime I think is is is quite quite nice um the one carat there of course being that um that is very much still subject to stability testing people are cautiously optimistic that we can do this but if um in the in the process of shipping the fork there are major concerns major problems that that emerged around that that that could still be reduced so don't yet base your

decisions quite quite on that logged in yet um now specific speically I said basically pectra has final scope now but there are two small remaining questions and both of them happen to be relevant kind of in the rollup context and so we wanted to use this call um with with the next Al of being tomorrow it's actually really good timing to get some feedback from people on this call and or for example if you on the representative from the team and you don't you don't have specific knowledge on these questions at least like that would be really high value to kind of make visible to the team so that they can give feedback by tomorrow and um um this is uh the first one actually we have Matt on the call to talk a little bit more about that is the question of um

there there might be a change uh in in pector that would make the um maximum blobs that are available in the block no longer be visible as a parameter to execution clients um and that could cause some issues Matt do you want to elaborate a little bit on that hey yeah uh most issue that we're focusing on is the East fee history RPC this is added when we added 1559 and sort of was designed to provide information about the fee market and for 444 we sort of just extended what was already there that we put in for 1559 and there was one field in the E history

that requires the max blob the max blobs per gas and that's the gas used ratio so I was curious if any rollups are using East fee history for blob gas and what implications might be if there that value is not accessible or that value you need to get from a different place than your execution client right uh I we have two r on this so um EV if you want to go first yep so from L side um we use uh e Fe history uh so we use it particularly

for for estimating the for providing the RPC point linear estimate G uh like which allows the users to like estimate let's say uh transaction or uh the the priority fees for L transactions and we also use uh the plob uh plob ratio for for submitting the blobs like do the Essen like to to provide good uh good fees so uh for the like for the second thing like for submitting Globes on L1 so we can like we can get uh get away with not using the the U blow gas used ratio so we can use like with other

methods but for the for linear estimate gas uh we don't use the ratio but we use the other fields in the history so the the RPC like in general is is useful for us okay RPC is useful but you're not using gas used ratio for plob gas so you are uh so uh we are not for the like for the uh linear estimate C we are not using it and for submitting the plops on L1 like we are using for now but uh we can uh we can like we can use without I see okay thanks awesome and

Peter uh yeah about the Fe history API at scroll we don't use it for setting the blob fees so we wouldn't be affected by any change to this II great um yeah that's useful context I could imagine that there are quite a few teams where the people on the call here maybe don't have the specific context on on on the specific um endpoint so if that's you um and you're unsure whether your team might be affected uh it would be really nice I think if you could surface this internally in the team so that ideally we have some signal doesn't have to be from everyone of course but if if it's if it's somewhat

representative um by ALCS tomorrow that could make a difference in ining that decision um t yeah uh I just grabbed our code in arbitr I don't think we use it uh for anything okay um that's that's helpful so so far it's one one out of three basically um okay then um Matt anything else you wanted to on this point um no not much on this point I just want

to say that we're not trying to break these apis and we're going to try to retain this functionality but it's good to hear how people are thinking about it u i don't expect a change to happen to the API at this point okay yeah that that's good context okay and then there is uh a second uh point where um rollup input would actually be quite valuable for tomorrow's um orod call and that is specifically the EIP 7762 which is proposing to introduce a uh Flor for the blood base fee if I remember

correctly Max Resnik was who's the uh author was on this call a couple roll calls ago um I'm not sure if he actually could make the call or if I present it for him but either way basically that this proposal has been out for a while and now um it's the one thing that so far has not been added to pector but is still is still in consideration as the last decision to be made by default it would not be included but it could still be included if there's strong demand for it um now the context here is that already today of course um there is if if the if the base fee is is at is is at one way so basically the very um floor that it test today basically the just basically zero um it takes quite a while to ramp up to a meaningful price anytime

we hit congestion and and and and basically there price Discovery um which is already not not not not not great ux um and and and specifically important here as context is that in Petra this will get somewhat worse and that is related to this throughput increase which as you saw earlier goes from this symmetric 36 to 69 and given that that and that was of course done because the maximum the is is that that's the critical value for for for like Peak load on the network and so basically we chose to not go to 612 which would just be too too much kind of worst case load for the network and the the tradeoff there is that there is a difference now in the basically the maximum responsiveness to demand spikes versus

um drops so basically um if the target is six and there's no blobs in a block that's a signal that basically we under shot by six blobs but on the on the on the positive side basically we can only overshoot by three blobs so the at full or completely empty kind of blobs the responsiveness is different and so we we chose some sort of Middle Ground value today every block can change the base fee in both directions by roughly 12% and now in the future it will be 8% on the that that the basy can can can increase maximum block block by block and 14% that it can maximally fall um with the implication there being that ramp up now is uh even 50% slower so anything that say for example took 30

minutes to to to do to ramp up from to to reasonable price now would take 45 minutes that kind of thing um which is not the end of the world the question is how desirable would it be um I forget the details but Max Max ran the numbers and basically it his EIP would in the normal case if we at the floor still not cause meaningful kind of costs for for for blob consumers but then it would be so close to the meaningful range that ramp up would now only take a few minutes and the question here is basically how desirable is this for rollups um and so kind of same same question if if any of the teams on this call have have an opinion of like how desirable it would be to to to create a a Bas V floor

higher than one way to shorten ramp up times now would be the time to speak up otherwise again would be valuable to surface this team internally so if someone within the team has strong opinions um by tomorrow would be a good time to voice those either just generally in the roll call Channel or by coming onto the AL call so yeah anyone Peter I just have a question for the motivation of this EIP is this to kind of address the paino for RPS kind of that the blob Market is not so

predictable so the goal is to make it more predictable and the um maintenance experience for all better so the predictability unfortunately while that's also a paino I'm aware and that that isn't really addressed by this unfortunately and uh that's that's a longer term research question where we are looking into things like uh making it easy for a Futures Market to emerge around blob pricing so so you have pricing predictability and that wouldn't be directly affected it is more about these um I think so far it's been happening a couple times like maybe to 10 times over the existence of blobs that we we hit this this congestion level of like actually hitting three blobs through put per block and then the price just takes some time to ramp up

basically to two levels um where where pricing happens uh through the BLS and and that has in the past led to rollups having issues getting their blops in for for a period of 30 minutes plus minus um so that pain Point specifically would be addressed like that that only happens very rarely it doesn't really affect things in the average case it happens a few times a year um but yeah that that specific paino would be addressed by this and so in a way the question is how much of a paino has this been historically for for robs I I'm aware that I I know for example from I know that um the first time this happened that I think arbitrum and also base those were two two robes that I heard of heard from that um were struggling with this um but yeah for

example would be good feedback if by now say people have just worked around this and it's no longer paino then that would deprioritize the IP to the extent that it would not make it into Petron Evo so from our point of view so like we have essentially worked around it so we can have a delay when when boting the blobs so yeah so it's it's not a very high priority and I guess like if uh like with this CP included like it would result in let's say more stable number blobs uh like per block so I guess like it will be like even like even better makes sense

um yeah so speaking for scroll I think we have a robust resending and gas bump mechanism so uh just the the fact that it takes time to ramp up is not a huge issue for us the couple of cases that as K mentioned I believe the main issue for us was that the Fe was actually spiking so the fees went like crazy high up and it was actually congested so if I understand this feif floor or U yeah that this floor price wouldn't help with that I guess the throughput increase would definitely help with that so we don't have a strong stance on the CIP okay that's good to know then that sounds like um on in general people seem

to think that this is no longer ASP of an issue which is actually really good to hear um that would then mean we will likely tomorrow not include the AP so then basically yeah for for maybe the people on the call where they didn't have the context for this um yeah maybe propagate that information so that if if there's any teams for whom that would be a big deal um be aware that like by default we we will not in include this this uh FL EIP so you would have to make your always heard pretty short notice to change that um and yeah it also kind of reinforces of course that indeed one of our main priorities on the L1 in general going forward including pectra but also for post pectra will be to to to

basically deliver a steady stream of blob throughput increases that I think really in the long term trumps all other ux um considerations around blobs um and so hopefully we can deliver deliver on that with pasas and Beyond um yeah then I think that is all from the ACD summary section so I'll stop the share and wait yeah one last comment Peter Yeah question about 7702 we're very interested in adopting this e as I see the status is review now so is there any known changes to be considered or it's more or less final at this point uh yeah that's a good point uh I

would in my mind the E is basically fine well um I mean Matt both Matt and I have are co-authors so we should know Matt do you still foresee any remaining spec changes to 7702 to me it really seemed I would imagine that there's a small chance there might still be like some small last minute pricing um updates but even that is unlikely and otherwise I think it will it will ship in the format is today yeah I think it will mostly sh the form it is today there's a few very small things around pricing and maybe bringing parody amongst the X code family and the code family off codes but pretty marginal changes I think the

mechanism itself is um yeah pretty much in the place that you can expect it to look at inet awesome yeah and I think in general with with 7702 um of course we on the L1 we all we're doing is we're shipping the capability and then the question is how how quickly will wallets want to adopt this anyway so I think with around 772 it would be really valuable for uh the individual kind of chains that are considering adopting it and um I'm not sure about the timeline yet if you if you basically just get a feeling for where the EOS system stands there how quickly basically we will get to a place where users will just expect this to work under the hood and where not supporting it on your chain would become

uh an issue um that's not really something that I think from the from the hor L1 perspective we can we can directly speak to but I I I would imagine it's it's a pretty major change to the ux for users and so I would imagine that once it goes live on L1 that like relatively quickly we'll get to a place where um it would be meaningfully impacting your users if if that's not available on your chain uh St yeah I have a question about ep77 NO2 okay so maybe it's not the right call to discuss it I can always do it I think and it doesn't particularly matter for Ms for S but there are some APS which were endorsed by vitalic and

they Endor the chain IDs for chains they should eventually become 32 byte while the current specification of 7 EP 7702 requires Chad to be 8 by 70 64bit so I don't know like are changes of this or order of magnitude still can still be considered or is it like very set in stone at this point I mean they could be considered but originally chain ID was 32 bytes as far as I know and a lot of client teams have pushed for it to become 8 bytes I'm not familiar with the zps you mentioned that ital sort of endorsed but

we were trying to understand if people are using 32 by Chain IDs and we just came to the conclusion that no one is doing this or at least no one who is using Foundry or W because apparently they don't support anything greater than eight bytes so if you have specific IPS or specific chains in mind that don't fit into this world um yeah I think that information will be useful and it is something that could still change okay thank you awesome and maybe is a final comment for me for this kind of this ACD update section I think in general um we've been

seeing on the L1 side that there's quite a bit of interest of basically having more visibility into the um priorities and demands of of of of of rollups on a lot of different topics I think kind of today the these two changes we talked about in the bottom part of the slide um were good examples um and so uh I feel like we've been kind of trial running these sections on Roo but I really feel like um on the L1 side they're adding a lot of value and for example tomorrow I'll have to go and apologize for basically pushing this Max um um the the blob base F floor EIP because I was under the impression that there was still a big Point paino fors turns out that seems to no longer be the case um so it's really valuable to kind of have that feedback loop and um yeah so we'll

we'll we'll continue doing that and uh so it's always quite valuable to to for robs to have someone on on the r calls to to have these this context and and be able to give the signals so yeah just wanted to mention that um yeah and with that Kyle back to you um yeah yeah thanks um are there any other discussion points people would like to talk about about changes coming in Petra in general seems like we've covered most of it but that would be a really good opportunity just as in because we have ACD tomorrow and one of the last ones so we discuss making any changes things are pretty locked

in okay um so then onto the ml2 focus topics uh we had a breakout um on the Common Core idea and I'm going give it back to Asar to give a brief summary of what happened there yeah a bit of a ping pong but exactly yeah um yeah we had a breakout call actually exactly last week um with many of you on there I think it was quite productive kind of um exploring the this this idea of given that we keep getting the feedback that the scope should not just be narrowly the evm but execution

in general I would say we rename it as the L2 execution Common Core um and basically uh what role it could play um going forward um first of all I think like one of the takeaways was just that there seem to still be a bit of confusion of the relative U or like the the the the different terms I just wanted to clarify so we have the rollup G um project now which is a for of G that basically just aims to provide to providing basically a um IP um aware kind of version of of of of of G um that that that will over time kind of implement um a lot of the IPS that gain traction um and in that sense just basically

establish parity with other clients that uh like like NE mind like like re like um umu Aron like all the clients all the um evm clients are basically now willing to to to to implement and maintain um IP of course don't want to speak for everyone but but but from the signaling we've we've been seeing uh Implement basically they two specific features which is quite encouraging um so so they basically the the piece of the puzzle r is really just about making sure that no matter what clients you use asl2 you have access to iips um and then the common core is not directly connected to any specific client or anything that's really just intended as a potential kind of set of of like bundled set of of ips

bundle set of L2 specific features to make it easier for the ecosystem to basically um um understand what features to support um and in particular for example on the call last week we had some feedback from from the wallet ecosystem that for them it would be quite desirable um quite valuable to have something like a common core where they know that ah these features um are going to be um um supported um maintained by by by by by a large subset of the L2 ecosystem and so for that that would help them prioritize support for those features um so so that was good to hear and there was some some general discussion around the scope of the Common Core project in general um in particular kind of there there's

different um potential points of in in the design space it could be um more based on individual features like for example the um the R1 curve um something like native count obstruction in the in the in the medium term these kind of things um but there are also alternative ideas um Proto for example from the from the op side um presented um or like like I was talking about about the idea of of of of of of focusing more around um basically EXT extension points in the execution system that that allow for the individual elus to to build features on their own um in in in a in a way that basically reduces the diff that they would have to to the to the to the L1

clients or to to the evm clients basically um so so the question basically is a question there is like whether the Common Core should should basically be opinionated on the feutures or just just just build these kind of extension points but leave it up to the individuals to then pick and choose um that's still kind of to be determined in a way um and then there was some discussion already around a potential scope for um for a first version a potential first version of the of the common core standard um that that was only like in the beginning like in the early stages though um because then we also ran ran to the end of the of the session um in terms of specific next steps there um I was uh think it could make sense so

so so we'll have another um breakout call um actually because of the holidays and everything K and I were thinking we would Target the 22nd of January which is yeah another Wednesday for for basically breakout call um but to make progress basically on to make progress on working towards a specific set of features that that could could make up the the common cor V1 we also creating um basically a kind of Common Core of you one working group so if you you are specifically interested in kind of joining that uh I will put the we have a telegram group uh I'll put the link to the telegram group here in the chat and then I'll also put it into the roll call Channel um and don't feel at all kind of

obliged to join this this is more supposed to to facilitate somewhat more active collaboration on this topic and all all that the output here will be is is not not some sort of pre-agreement it's really just about presenting the options so on the next R breakout calls we can talk more about specifics of like hey this this is what a scope for the first um Common Core could look like um and then of course we'll still have to iterate with a group to make sure that that that we actually find something that um is uh sensible for for for large set of of participants um and of course there's still an option to to decide that the common core is not the right approach after all we will see that on that call and but basically if you for example do not have the the availability

to like work so so actively kind of in the meantime then then it's fine maybe you can you can skip skip that group and then just attend the next breakout and and and we can um we can see um B and take it from there so this is really just as like an opt-in exploratory group meant as that um also don't know if anyone else was on this call last week and feels like I I was I was forgetting anything in my summary uh do do feel free to jump in and mention that or if there's any general uh ideas around um other next steps now would be the time

T yeah again I think one point about the common core is that if we're looking to do some sort of a spec that shows What's the different what all the different rollup support it makes a lot of sense to me but I think that ignoring all the difference that currently exists and just saying we start from whatever we have right now that part I don't understand like there are the different rollups already are different from the evm already are different from each other and I think that uh uh making some order in that uh

would be a Worthy go right um interesting that that that actually is that's something that I indeed forgot in my summary so there was quite a bit of discussion actually around um say given that different l2s are currently evm equivalent but that doesn't mean they have identical specs it of course means that there's still some difference how that how would that relate to um the the common core and uh kind of the conclusion there of course is that also on the Common Core if um there are featur es and you're part of the Common Core that there's still of course the the possibility that just as youm equivalent but then still make small changes to the evm that you ship a feature of the Common Core but because

of some architectural spec specifics of your chain you might have to modify it um to some extent so so so basically the equivalence here to the to the Common Core would be similar in its flexibility to the to the equivalence to the VM in general um it's it's it's it's it's really more of like a a general set of features to be orted um but then also and this was kind of to to to what just said basically there was in general like a desire to to see how how would that relate to mapping out the existing kind of differences across the the the the the the rollups and potential ways that that could be harmonized in the future and um that is something where we'll

we'll have to see over time basically to what extent tracking that uh could be in scope for for an effort like that um there's also some existing ecosystem um parties that that do a really good job in at some subset of that so for example there's um I think it's roll up. codes which is really nice website um tracking tracking that on the on the kind of the the evm kind of um up code level um so so maybe there could also be collaborations with ecosystem Partners going forward and niik uh yeah this was a reaction to the dates you mentioned before you mentioned the 22nd of January for next roll call is that

it so that would be specifically for this breakout break okay okay yeah yeah yeah that's just a breakout because the okay sure yeah um I think k k wanted to speak to um the next or the the the the general roll call schedule um at the end of of the call if if I'm not mistaken but yeah so that's specifically a breakout and I also I can actually link it I have a GI up issue maybe that's useful for people uh I'll link it I'll link it in chat um for for this next breakout great thanks ancar um any

further points that someone would like to raise or discuss like General points of discussion before we wrap up great seems like not um okay so the next roll call is would be very early in January uh I the 8th and I don't think as like there'll be many changes or things that need to be discussed with everyone here before then um so I think rather Focus energies on

the Common Core efforts uh that unsore is just mentioning so the idea is that we'll skip the January roll call and rather have this breakout um on the 22nd and then resume normal roll calls on the second week of Feb so we'll see everyone there second week Feb and yeah thanks all for attending by everyone