RollCall #10

Transcript

hello and welcome everyone to roll call number 10 uh this is issue uh 1216 in the ethereum PM repo uh Link in the chat for the agenda uh okay cool let's kick this off so uh starting with some few updates on the L1 um I'll give it over to Anar to talk about uh tecture upgrade timelines yeah um I have a i sh my screen one second um this and then you see my

screen yep you're good awesome um yeah so basically just just a few quick updates so um uh pectra basically we uh have just now kind of last week on orod def's picked preliminary dates specifically we've picked dates for the test net folks yet uh so far and then we have basically picked a date where we will choose when exactly it will it will hit main net but we have not actually picked the specific main net date yet um and so so these dates are um we will have client releases out um by tomorrow the different different clients and then tomorrow or on Friday there will be a an announcement um blog post um on on on the theum

foundation blog um then the actual kind of test net forks will be heski will be on February 24th and zolia on March 5th and then assuming all of this goes smoothly the idea would be that on the day after this poio for on March 6 we would then basically make a decision on mainnet uh roll out with the default assumption would being that um that should be roughly then be aimed at mon after the um after that that day um that's has been historically that the amount of time we wanted to give stakers to update at the notes and everything so assuming again everything go smoothly you could expect um the um the the hard for to go live on Main it around April

8th plus minus a few days um yeah so that's that was basically that on the on the roll dates and if if for example you you you want to test things on the test Nets then then those test Nets dates of course are for Relevant for you so um one point on um on updates from orod devs then there was another one request for feedback I'm not sure K did you want to talk about this or otherwise I could talk about it as well I actually asked Kev one of the EIP authors to uh join so you could ah perfect speak to it I'll keep sharing my screen just but unless ke wanted to share screen uh yeah thank you um yeah so we wanted

to get some feedback on this uh ERC on uh allowing local block Builders to specify the maximum amount of blobs that they can uh put inside of their own block uh and basically see if there are any issues on the L2 side uh I think one that we fielded so far is that uh l2s usually Post in batches of five or six blobs uh are there any sort of others you mean other concerns yeah yeah so there's specifically been a concern around um the pricing as well so

basically for the 1559 mechanism that we use for um for for for for BL prices as well for for that to actually re have an equilibrium price that it stably stays at more or less you need to have at least the average throughput has to be at least at the Target um and you could imagine if the ra if the if the if the portion of um people of builders that basically that that now limit the amount of blops they include um and they limited to a value below the target if that becomes too large then all of a sudden the average can't basically stay at or above the target anymore and at which point basically the the the the blob fee would go down to zero or even once you already kind of get close to that level the volatility of the of the

of the blob Bas you would would would become larger and and so so basically one one question from the otive side like now normally because of MEF boost that's that will usually not happen but you could imagine if there's an issue with MEF boost people revert back to local building many people have set the flag now you're basically in a situation where um the the blob fee becomes more instable uh unstable and so um yeah so so a a question specifically was how much of a concern that that would be for lus maybe Kev do did you want to like

make a little bit more of the case for like why why would this uh flight be be valuable uh sorry yeah sure um so essentially uh there is a sort of a hardware and bandwidth requirement doc uh that we've been sort of uh trying to standardize for a while and one issue that we have is that uh there is there are home stakers who clearly don't have um sufficient uh bandwidth uh so either we set the local block Builder bandwidth to be sorry the hard de bandwith requirements to be that of sort of home stakers or we set it to

be somewhat of an average uh of uh we've used the average of sort of the global average and then we allow home stakers to sort of set their own uh numbers this essentially allows us to uh scale the blobs according to this uh global average number while still keeping local uh home stakers sort of on the network right and so yeah just to to add to that from my point right like we're basically currently we are actively exploring how to how our kind of blob scaling road map should look like and uh one concern there is that while we where it's pretty

easy to make the availability sampling more efficient I mean literally right now we're doing the most dumb thing possible on ethereum where basically everyone just downloads all the blobs to check that they available that's of course a temporary solution while we rolling out like a sampling based approach but even once we have the sampling based approach you can make that more more efficient over time so basically you can increase the overall throughput on the network and still the per node kind of like download bandwidth to check the availability um um is basically still uh can can be relatively low um the big problem is that the one bottle neck that's a bit harder to get rid of is the Builder so the Builder basically right like because the moment you create the block you also have to rapidly seed all the blobs to the network to then that they can then be

sampled um and so basically the two schools of thoughts here would be to basically really keep keep the the overall blob throughput very low to to allow for for for local Builders even with with with basically limited upload bandwidth um to basically like limit the throughput of the entire network because of the the slowest nodes basically um and then figure out like maybe some long-term Solutions with distributed block building or something the alternative would be we say okay we want to actually scale a bit more aggressively bit faster and but it would come with with this trade-off of basically having to introduce a flag like this which could basically um have some door backs so basically the question would be for L2 what what is more important I mean a little bit a

little bit like simplified but like would it be more important for you to have five times more blob through put or would would be more important for you to have very stable blob fees basically which if if you if you can only choose one of the two which of the two is more important that's basically a signal that that'll of is trying to to get right now yeah so either if if there's anyone on the call right now that has any like strong opinions from the L2 side on like whether you you need more Fe stability

or more higher blob throughput that would be good to hear otherwise also like yeah again you can you can relay that question and then um if someone on the team has a strong opinion um ideally kind of filter that back to us or just directly kind of have that be visible to the C of process um I just have an opinion I'm just trying to um understand if this will um be helping um because this is an ERC or maybe whatever rrc if it turns out to be for roll up this is not a mandatory one for people like so even if we are having this proposal in we are kind of providing an option to uh Layer

Two to maybe pick up between the uneven distribution and high blow fees however I believe that we have 7691 already planned for Petra so that could help with some of the even uh distribution among the FL or that is already providing the new Target thing right yeah so this um this ESC is not directly targeting l2s at all this is basically just for um clients um to to to to expose a new defa parameter that would then be be be set by by by stakers so the question is basically just if we do this um should this make us comfortable starting to scale blops more

or should we basically not do that because the downside of potential Fe stability is out ways the the extra bu through what we could get maybe just from linear point of view between obviously we are interested in having Fe stability but having higher frut is is more important okay that's good to hear I think kind of that that was the intuition that that that we all K and uh Kevin and I already had but but um yeah having it like hearing it directly from

the at I think is is is a much stronger argument we can then bring back to the to alod devs um rather than just basing it on our intuition uh evil yeah so to add on top of that so like on linear side what we can essentially do is that like we can slightly delay posting the blobs uh and so I think like uh let's say it it w't affect us uh like too much like if let's say like if there are like a lot of like a several proposers like like in a row like who who want to include less blobs but uh like how like uh do you have like envisioned like how it would

affect uh like pricing the blobs because let's say like if like if there there are like several proposals like uh willing to include uh less blobs so like it would also mean that like we let's say the average or like for the the running average of of included blobs like it would decrease a bit so like it it would also affect the the the uh the like the blob base fee so does like are there like any compensation mechanisms for that or yeah so long term we can definitely look into compensation mechanism so for now basically the effect would be you could imagine that in a couple months especially once we have the fusaka for that that will come after Petra we will

have a relatively like big jump up in the um blob Target and maximum um and at that level it could just be that occasionally yeah as you said there are several proposal in a row that all do not even reach the um the target even though that there would be enough demand just because of their local Flags um and so that could mean that occasionally basically the um base fee could artificially fall a little under under the equilibrium and then you you would basically have a situation where for several blocks in a row um there would be basically more more blobs than than there would be room and so then you basically you would have to fall back to a either just waiting for several several uh slots until you basically

find room in a block or you basically have to revert back to a first price auction bya the tip um and so that is a bit of extra complexity for for to because now you have to have that logic implemented right to basically either I mean you can always just submit the transaction and it'll just take a little longer some sometimes to be picked up or you need to have logic around um recognizing when that happens and um basically setting a tip that that accounts for basically the priority you would want to have um and again in this in the unlikely scenario that there are issues with me boost and it could be that like the the the the base feed could fall quite a bit so it could possibly even for a while stay at one but basically go all the way down

basically to to to the minimum and and then stay at that minimum um for an extended period of time at which time Point you'd basically have to send like like um attach tips to your to your blob transactions to to make sure that they um can still be picked up um it might also be useful to note that without this flag if we do scale uh in sort of the happy case the local block Builder would just probably miss the slot uh instead of proposing with like less

blobs right but more likely we would just not even scale as far to begin with and so then um if we basically if if we were to decide that we would not ship this this flag then what that would probably mean is that we would say eight months from now nine months from now we would only have half the The Blob throughput so basically opting opting into the flag means opting into more blobs and on that point I think that's why this kind of is a consensus item like it's not it's not a part of the L1 consensus but we would need to have it would be necessary for us to agree broadly that we need to have this included in order to be able to uh push

blob scaling to sort of average throughput levels as opposed to be limited by the slowest nodes okay okay yeah I had should I add one more brief quick brief side from the ACD set you um and that was I mean that was in a way like the most open-ended one I just wanted to flag it not sure if there's even any feedback on the call now but uh basically just just to you're aware right now on the L1 side there's a little bit of of an active conversation around uh what should the uh road map

priorities be um not not so much the road map itself I think we have a pretty good grasp where where one wants to go but in terms of like in the roll out um Whenever there are more features then we can fit into single Fork like how should we prioritize that like sometimes there's there's there questions around should a for wait for to so we can add more features or should it be rolled out as quickly as possible so basic we we currently are revisiting how we prioritize um shipping features on the L1 um specifically also because pectra like we Bally ended up having to split the fork into two to make it still shippable uh sized chunks which for example delayed the the the P roll out and delayed the The Blob scaling a little bit um so yeah of course there different stakeholders on ethereum so um

different people would have different priorities in terms of what what is most important to them I just wanted to list a few basically different like this is not at all conclusive or or specifically representative just like types of changes that that that one could prioritize and and so um clearly the l2s would have a specific kind of partial interest here but um just wanted to say like if if there are specific things that you think the L one should really prioritize for example we've heard over the last few weeks talking to different l2s that for some some at least um the kind of The Blob through put really is starting to get like quite the constraining factor and so so that would for them be the most important thing but that's not true for everyone some others also for example lik that with 7702 we

we we we shipped some ux improvements on the evm side so again just in if there's any specific things where you feel like you would personally wish that um or as a team would wish that the L1 would basically have more of a priority for um then I think that would just be really good to to hear to make visible mention it now or come talk to us or just mention publicly so that it filters into the CF process I think right now is a is a moment in time where that would actually have quite the impact so I just wanted to to mention that as my last point from the the L1 side great thank you

alar uh okay on to the next topic um Josh Rudolph wanted to give an update on how the interrupt efforts are going so hand it over to Josh hello hello can you hear me okay a little soft but otherwise we got you okay let me know if you need me to talk louder sorry it's a little early my brain isn't fully activated yet um so bear with me but um yeah I'll just give you all a quick rundown on some of the interop efforts uh I think maybe many of you listening and listening here now and to the recording will already be aware of this so I'll try to keep it short perhaps and um yeah please reach out to me if any questions and we can also um

yeah follow up on this but so yeah so the quick overview for folks here is um as I think many of you know we started this L2 interrupt working group in January um high level idea is to bring everyone who is working on interrup across ethereum and see if we can accelerate both shipping of near-term solutions and also improve coordination around longer term initiatives and trying to balance both of those things together I think um just I guess my personal take is that perhaps we haven't optimized enough for some of the shipping of of near-term solutions and so I'm really spending a bit more of my time there uh at the moment uh and overall just the theme of how do we

unify the unification efforts there's lots of different interrupt efforts happening across the ecosystem uh lots of coordination efforts and yeah yet necessary to I think it would be preferable for us to better coordinate the coordination so uh we've had two calls so far from those calls we've had uh three separate tracks get created these three tracks are number one chain specific addresses number two cross chain messaging and number three intents um we're fairly High conviction or I guess I should say I'm I'm fairly High conviction that all three of these will will play a big role in in near-term unification efforts uh but perhaps intense will be the most likely

path to actually us shipping something to users in the next three three to four months uh and well chain specific addresses as well will play a part in that um and again I guess that's really what um yeah I've tried to I've tried to keep the group focused on how can we move faster and ship something in these next 3 to four months TBD exactly uh around yeah what what does that mean exactly to ship something in the next 3 to four months is that realistic or not and and just what is the highest value thing to ship there um would also want to do it of course in a way where it doesn't cause us to get stuck at some crappy local Maxima but rather do it in a way where it also accelerates and supports the longer term efforts so I'm

trying to keep an eye on both things uh I guess a couple just final points with regards to intents that's where I'm putting again more of my Focus for the moment uh there's been a really yeah I don't think this will be a surprise to most people um with 7683 and other efforts there's been a lot of momentum and progress happening here and um yeah we should have more actually to announce around this on our next call which is tomorrow would be great for anyone who wants to to join that um yeah ping me for more information and I'll I'll also post it here in the in the zoom chat um so yeah I think that's that's it sorry if it was a little bit all over

the place that was are just my my quick notes uh on inop um and again yeah anyone that wants to jump in be great L2 teams wallets anyone who is uh working on on anything related to this or just have an interest in this uh and I just noticed we also have Skelly Skelly here in the in the in the zoom call right now and and he's been playing a a big role uh Wonderland um has been has been yeah really great and jumping into some of these interop efforts so quick shout out to to the Wonderland team um yeah that's it for me great thank you Josh anyone have any comments questions about that

nope all right um so on to the next topic uh there's an overhaul of rip 7859 uh exposing the L1 origin information side the L2 uh execution environment I don't believe the author is here um is anyone else who like to give an update on that we have context exactly on what was happening there okay I'm going take those a no uh then moving on to the next topic uh is new rip 7875 I'll hand over to yov to talk about yeah

hi okay so um yeah rip uh 7875 it's a it's a related to the related to ERC 7802 which standardizes uh standardizes token mint and burn Bridges basically uh uh basically standardizing the way uh tokens Can Be minted and burned on L2 when receiving messages from another chain whether it's L1 or another L2 so um with this ERC uh with this ERC we noticed that tokens tokens embed the trusted the canonical Bridge address uh

the token the the 7802 Bridge address in order to uh to trust it so it affects the it affects the tokens the token code and therefore the token address so we we are proposing an rip that standardizes it uh that standardizes the bridge address a while ago we uh a while ago we introduced EAP 78 um yeah 7 7587 which reserved a a range for RP pre compiles so we are proposing to use one of these addresses and set it as a token as a token break

so that when you deploy tokens on an L2 whether it supports 7822 or not uh if your token wants to support it it should use this it should trust this address and then at any point in time if the rollup adds support for such a token Bridge we know that these tokens are going to be future compatible and of course they get to be in the same create to address because as on other l2s because uh they all have the same they all share the same trusted address so sorry if I sound a bit a bit confused here I also also a bit tired but any questions about it I have I have something to add not

sure if you guys can hear me okay um yeah but one the yeah no worries uh thanks also for the for the intro um one of the key things that we're trying to do with this RP is that we want these ERC 20s that have no owner to be able to be permissionless deployed in a safe matter pointing to the same Bridge address on different ecosystems this is mainly because for example op or RP or any other of these new let's say cluster of chains will have their own uh let's say ecosystem bridge that is not necessarily the same as the canonical Bridge pointing uh from L2 to L1 and and backwards

um the thing is they will probably have Bridges connecting either from their L2 to their l3s or from the l2s to their sibling l2s such as in op introp uh and these specific bridges are the ones that will uh start to use this kind of cross-chain mint burn interface and those bridges are not necessarily standardized in any way right now so tokens that are um say just vanilla um cross chain ERC 20s will need to have like modifications depending on which ecosystem they're deployed on so kind of propagation of these assets become becomes a little bit

of a headache uh both for Developers for users and for let's say offchain infrastructure uh such as relayer solvers same for intents so this is kind of um a solution that you have had uh kind of future proving some of the headaches that we might have without of these uh cross chain asset transfers so anyone anyone here has any questions about it

fantastic thanks you all and uh see you lat um that brings us to the end of our agenda does anyone have anything else that would like to uh raise SL discuss well um I could give a quick update just from the uh working group from last week um so last week we had like a roo breakout on um basically exploring the evm or the execution Common Core idea having having a bundle of ips that that basically would all have brought support

across multiple lus and and we could basically make them the canonical set of of ips to to support for wallets and and and and the kind of the tool chain in general um is so that there's less of fragmentation uh there were some discussions there already kind of in the in the leadup to the to the call um in general it it the sentiment seems to be that like it is a bit early right now for that specifically because we just don't have that many uh individual IPS yet that are live or close to life um I mean we have the R1 curve um 7 to 12 but uh other than that uh just not that many IPS kind of in that stage yet so it's it seems like a bit premature um so so basically we'll revisit the idea once we

have a few more IPS um at least close to to to ready for roll out um and then we we discussed a little bit kind of candidates that are currently being disc being discussed um for one there was definitely things uh there was there some some some things related to interop that came up there was the the l1s load the the static call um ideas um um but that that I think would if if if that if those IPS move forward then more through the interop side of things not so much kind of from from the rollal side directly and and then one last thing there is that one uh potential for future standardization for future IP that that I personally am quite excited about and would want to

try to move a bit along over the next few weeks or months um is the idea of having a standardized um transaction type or of a fee Market um for l2s um and they are basically uh what we did so far is I created a um document I'll link it in chat um with basically the uh design considerations of what what what would such a transaction type look like um I can maybe briefly I don't know just like just like 30 seconds give you like a quick overview so basically the idea here would be um just to say that in principle we kind of really need a multi-dimensional um uh fee Market

mechanism for l2s because there there are these like different fundamentally different types of costs there's the L2 execution cost that's more parallel to what we also have on the L1 and but then there's specifically also like the settlement cost uh the data cost for the that that basically is like a pass pass through cost from the L1 and then there at least for ZK rollups things like the proving cost and so actually exposing that in a multi-dimensional framework would be quite desirable and the nice thing is that we already have proposals for multi-dimensional uh fee markets on the L1 anyway specifically there's e 7706 um which would basically split out the call data Dimension but the nice thing is vitalic proposed it in a way that would be uh basically Express uh these Dimensions as just like a vector

of Dimensions so that it would start out with two on Main net but it could be EXT extensible both on Main net with future Dimensions but then also on the l2s so the the goal would be to like explore this and and find a a setup that basically is is in sync with where where the L1 is going there um One open question there is just do we basically then have to move at the speed of the L1 and wait until the C moves far long enough that we can make sure that there's no ends up no being no no subtle incompatibility between the two types and we'll have to see maybe we can also have the L1 commit to using the L2 type even before itself kind of moves forward with that um yeah there's a few extra uh uh aspects like the the kind of

compatibility with account obstruction um where where exactly would the would the standardization boundary be um uh to to what extent basically to actually expose the the the multi-dimensionality in the transaction type or just in the underlying mechanism um extensibility inter considerations so a bunch of these these things um so it's by by no means like an IP or anything yet it will require some some some further exploration to to get to a specific proposal but it seemed like there was um meaningful interest in basically that once there would be a proposal that works for for for the um for for what L2 need from it then I think that could be a very reasonable candidate for standardization so yeah

just wanted to mention that um yeah but but basically a bit premature for moving forward with with the common qu idea for now and and see there was one question in the chat how does this relate to the work being done by The Oasis etherum L2 group yeah that's a great question that came up on the call as well um so basically they are focusing a lot on specifically standardizing the side the the part of the the kind of the mechanism that does not actually require changes to the L2 itself or to the including say new transaction type but just the interaction between wallets and and l2s right so basically the the gas estimation and that kind of thing um so in a way it's it's orthogonal or

synergetic to to this right so basically uh you you could imagine that there might need to also be an extension to the kind of that that existing standard that they're developing once once the fee Market itself also changes but basically their approach was to basically standardize the thing that could can easily be standardized even even without IPS um but B but but the the more fundamental kind of solution is to to then also have a standard for the fee Market itself not just for how it is exposed to wallets but yeah it's not compete it's not competing efforts or anything that they're very much synergetic fastic thanks SAR uh any

other discussions such things people would like to raise before we wrap up great okay thank you everyone for joining um if you haven't thought much or basically your feedback on the uh discussion about around this new uh flag on the L1 would be very much appreciated um if you haven't thought much about it or you feel like there's someone on your team who could uh give useful feedback there uh that be very much appreciated um and could potentially

impact the long-term scaling of blobs dramatically on the old one so yeah would recommend doing so and yeah thanks all see you thank you