RollCall #7

Transcript

um hi everyone um welcome to the seventh roll call uh today I'll take over from Carl Carl is on the call but traveling and has somewhat unstable internet so I'm sure he'll be able to jump in but I'll I'll um lead the call um yeah we have uh some agenda items um I know that Max resnic who basically wants to later on talk about um The Blob uh transaction um The Reserve price um has time constraints and might only make it for short portion of the call so we'll basically we hope to to be able to time it so that he can briefly talk talk about it otherwise um I can I can do that for him but um I

wanted to first start by giving a very brief kind of update from the layer one from the aloda side um and just as an a quick short experiment um because I think this is generally useful um I have a very basic um presentation one one sec I I'll try to share my screen it's just two slides but I think actually having something to look at is generally nicer let's see if this um if this works can you see my screen yes I just yeah okay perfect um wait this is the slide two already okay

um slide one so so so basically um uh so first just general EIP updates uh oh both of these updates by the way will be specifically regarding the upcoming pectra hard for the that hard for is currently under planning it's not um basic not not not not super new term yet um but but basically the kind of the eips are more more logged in for it so um I think it makes sense to start kind of looking looking at how that affects lus as well um and so on the general e update side I I think the one thing that is worth mentioning here is the EIP 772 that is the um the set EA account code one so basically it allows EAS to to act

and delegate delegate to Smart account implementation and act as a smart account onchain um and so I'm bringing it up specifically because in the past it underwent several pretty um major iterations and changes and now basically the um uh General uh consensus has been that that we have reached a stable state so of course there it's not 100% certain that there won't be any tiny remaining changes but basically the spec as is will will be most likely more or less the spec that reaches the chain so if you as a layer two um have any kind of um General thoughts around um wanting to support this in the future but have maybe been holding off now would be the time to start kind of um um working on working uh on it I would say um and so

in particular um I I just want to mention mentioned that that my recommendation would be that that ler to try to to basically be ready to to support the this this feature on a similar timeline to to L1 because users will um of course on L1 be able to to start using it pretty soon and then they will expect to also be able to use it on layer twos um so unless you specifically have reasons to not want to support it at all I think it would be valuable to to try to align the timeline here with the with the pectra um roll out of course the details there still are TBD um and then one more Point that's maybe not quite so obvious that I wanted to stress there is that um given that with these um smart accounts we expect that the um um infrastructure stack that's

mostly used to bring these transactions to the chain is the kind of the 4337 the es 437 smart account standard um it would also be good um and that's something you can already do today because of course these these the standard is already out there in life and that you make sure that um your your L to is is um as compatible like basically that that that is as seamless as possible um to use M accounts via that um uh standard um yeah and that's uh I don't know is there any any any feedback any any or sorry before we go to the second slide any questions on on 7702 okay then I'll go to the second

Point um so there I just wanted to uh briefly highlight something that maybe is uh not not yet on everyone's radar so uh p is uh is of course the next scheduled hard for it actually turns out that like because there were a lot of um um features oh wait also I see I'm not aware of the chat let me double check that there's nothing in the chat um ah what is the ETA on on 7702 um yeah so basically Thea is just um whenever whenever pectra will be shipped which um we we have Alex on this call I'm not sure if he's comfortable giving predictions but like I would I would say something like first half of next year

um I think that is um you know like hopefully early in that in that window but um you know realistically um sometime first off next year is what I would say um uh well and that doesn't include UF and pasas well this is kind of the topic now so basically the the so so that was for now just talking about um 7702 now pectra initially is planned as one for but of course now it has been shaping up to be a really really large F there were a lot of like last minute editions pus was added relatively late um UF was added relatively late it it in total made made the fog um unusually large so now there is um uh at least um some some cons

considerations around possibly splitting the fork and rolling it out into two parts and this this is for to be clear not confirmed yet this is just um being discussed but I think it's at least not not unplausible that it will will happen this way and specifically just in terms of like the current state of the spec Readiness and testing and the most likely and most natural kind of candidates for that that would be pushed or the the main earps at least that that would likely um then be considered only in the second part would be um both EF uh and pias and of course both of those are at least in principle um also relevant for l two to the extent that the to would want to Alor ship UF and PE uses of course much more directly because it it will bring the next major

blob throughput increase over 4844 um and so from my side here I just wanted to I mean first just highlight that this might happen and so if if we end up with this two SP two part split then we would chip the first half of the for and and then I would really be very optimistic that that would be early early next year um um and that would most likely still include 7702 I don't think that is a Canada for for the second for um but then these features specifically might might be delayed until later in the year um and so I wanted to First collect a little bit of feedback here in terms of like what urgency people feel specifically say um I think it's it's it's more more question on p on pias so like how right now of course blobs are still

practically free on mainnet it's not guaranteed to last forever and specifically not guarante to last for say another year how urgent do people feel like a throughput increase there is um and then yeah depending on on that we can basically talk about how how people could make their opinions heard um on that point but I'd be curious about feedback first if anyone has thoughts right yeah I mean um if if we don't have any

anyone on the call right now with a very strong opinions which those people are usually rare um do do we a question in the chat do we predict pias to be severely needed um well I think basically the question is how soon will it be needed right so um I think it is definitely um crucial that we do increase the blob throughput in general it is to me also a question like how urgent is this right like I think I think it would be a huge lift to try like if I think at least again Alex would be more the expert here but like my my feeling is that it's it's really starting to become more and more challenging to have pasas kind of go live together with with the rest or like the the first half um of of the fork so

um the only reason to to basically double down on this and and and push very hard to try to to still make that happen would be if we if we perceive that there's probably a lot of urgency right that like say the difference between a throughput increase going life in 6 months or in 9 to 12 months um would be would be um would be severe I don't know I'm I I personally you know I'm I'm I of course I would want I want they they one to to have the best features possible for the l2s but I don't know like I feel like that's some that's like a a question that I feel like the l2s are a much better position to to have an answer to so um I'll

just me up uh yeah I mean another thing to consider is just uh like riskwise small hard Forks are much better to ship um so that's like another consideration and yeah again I think timelines are very up in the air um but if it is the case that peros uh L1 R&D doesn't proceed as quickly as you know we would like then this is an option like you're Ling out right um and maybe just to give a little bit of context because um I see that question chat as well so basically how does p in general affect like um the the

the the the block through put and and what is the plan there so basically um we we have right now with the 4844 of course shipped for the first time blobs as a specialized database ability kind of service from the R1 and so far this is not yet sampling based so meaning that every note in the network still downloads every blob that is how you check the the availability um the road map for ethereum is to move to sampling base so so basically what would when you when you heard about dun sharding in the past that specifically refers to the concept of of of a sampling based um data availability check um initially there was more like a binary um change so basically one a onetime shipment like like shipping this this this um

this sampling feature but by now we have a much more iterative um road map so there will be basically several rounds of more and more uh intricate um sampling that will allow us uh to to to have higher and higher kind of throughputs in terms of number of blobs so the initial pust will allow us to go beyond for before but I don't want to you know like um promise any specific numbers but I my my my own mental model is basically that like over the next three years or so we would want to have one roll out of of an improved sampling um mechanism every year and and say roughly 3x the throughput every year um maybe we won't be quite quite be able to stick that schedule but more or less rule of thumb so um P would be 3x the throughput of 4 four um and then

hopefully the year after so we we can we can further improve on that and so on until we basically reach the full um um sampling um sampling based um Super Targets that that that are associated with with full D shouting um so so really for now the question is just how soon do we basically need um this this first step of of increases over the count throughput levels um but of course that somehow um finding a compromise between the need there and the the the Practical realities and limitations of of this very high very large fog um and if if if there's like no no no very strong opinions on on this call which again I was just curious to check whether that's the case then I think for

now it's really just PSA basically so so people are aware that this is um a process that's happening and I just wanted to basically mention if someone maybe for example also listen to this recording later on or something and is um maybe some some rollup team has strong opinions there I I do think what would just be valuable would be to have those communicated in in in in a helpful way so for example like a blog post on um expressing kind of the the the relative priorities on on upcoming um features from the one basically and like how how that affects l2s and and and what are what the priorities there are and the timelines that would be helpful um and then possibly of course depending on on the the level of urgency there um

I think the alod process is always open for for for guests to come in and and express opinions directly so there was always would always be an option um yeah I think um I basically was um kind of as I think the our role as role call is basically to try to bridge this Gap so I just Bic wanted to make this as visible as possible for the for the who said um yeah I think that would be all then on the topic of um the update from the ACD process um I think I'll I'll stop my screen share then for the moment um yeah let me just briefly see uh um Andreas are you already raising your

hand for your own topic or is this still no I just I just have yeah have a have a quick question do we have actual number what the um what the um expected throughput increases are from the different l2s in terms of growth so to to to be able to Overlay that versus you know the the the increase through put on on um on on blobs right I mean if you're if you're if you're you know if you you know do like 2x 3x increases and you're actually just increasing by you know 40 % um you know year right then the question is what's the what's the proper

alignment with the growth path of lus right it it's it's just a just numerical exercise whether someone someone has actually collected that data what the expectations are versus what what's being planned right otherwise you're You're Building um building an 18wheeler and you just need um you know an SUV right yeah exactly and I mean I think of course I'd be happy to hear about uh on this point from the L2 directly as well but like I assume this is something that's very very hard to to predict and project and to some extent maybe also like business uh information that they would not necessarily want to

disclose um this but but so so that's why I see our role more on the from the from the base layer basically be to try to be as predictable as possible so that then the l2s can have certainty in their own planning and know what what kind of throughput levels they can they can Target while consuming L1 data um car the point is more just to be aware that if elus do not make enough noise about this then there's no real signal to the ACD process of how important this is and so if there is a

massive uptick in um the the the the need for blob space and we didn't make a noise about it several months in advance then ACD wouldn't have prioritize it we're not going to have more space for blobs and the poster blobs is going to go through the roof as demand SS so it's more heads up that like hey if this is something that you can see impacting you which I like definitely can see being a use case without like knowing the the the details of what's happening for any particular L2 but like just in general I can definitely see this happening and so it's like supposed to just be encouraging like hey you should stop making some noise about this if this is something you are thinking

about or um a potential for right um although of course again you know just to not make Alex too nervous this is with the understanding that there might be there there are very practical limitations right like it's the fork is very large and so even with um a lot of public support for in like AAS as soon as possible it's not it's very very very much not clear that um it would be possible to to ship this in a combined way um but of course if to the extent that this decision is up in the air of course having feedback on how this is this would be is of course always

helpful to inform that that decision um yeah then I think we can probably move on to the next uh agenda points specifically Max is not yet on the call I know he's it's very unclear whether he'll he'll be able to make it so I can I can basically fill in for him there but I would then prefer if maybe we have Andreas go first um and then then I'll see to towards the end whether whether Max up or not and um so yeah Andreas you wanted to basically report back from this these um specific working group sessions and wanted to schedule some calls um so go

ahead thank you yeah let me let me um so the the um let me um give a little bit of background so there have been so first first item are the and I think that's the r Solly speaking easier one are the al2 transaction status um s like harmonization standardization um the um uh so there there was was a discussion um in the role call telegram uh the channel and there were some uh that sort of like prompted um the um uh working group within the um um ethereum open Community projects to to take that

up and make a proposal um what could be sort of like a minimal set of transaction statuses that um would be um pable to to uh to different al2 clients uh given the fact that there's significant implementation variances so that um there can be additional transaction statuses that are specific to specific outso clients um put out a uh e magician post um and also on an RP issue uh had several discussions um invited feedback several discussions um feedback from

from different Al and so it's like there's a current state of of the um of the uh of the spec that um see me share my screen here just to can I um can I share yeah let me one second uh let me figure out how I can approve that um just sent a request should be share screen yes I think I think you should be able now okay great thank you um appreciate it it's loading for

me now I can see your screen right right so this is just the um this is just the the the layout for the um Oasis um spec some introduction overiew glosser is not really um I don't want to waste people's time um would really is the is um just want to briefly go over the um uh the uh the statuses also just so for everybody's benefit you want to look at it directly here's the um here's the link um uh and then also there's a a PR for that so um we have um broken up the

different stat statuses in in three Cate in three dimensions definition trust assumption and uh transaction status code so similar to an HTTP code um so um do we have we introduced in the different statuses L2 pending L2 replac L2 drop Al to confirmed L2 included and L1 pending um then L2 included L1 included and L2 finalized um L1 finalized um so the there was there was some discussion about um finalized versus

included is is um um basically if it's included in an L2 um or should should it be finalized is a transaction always finalized in an um L2 what it's included in an L2 block or not um what does it mean when it comes to know de centralization of the sequencers so there was some discussion um around it I think the the loosest um uh wording and definition was around included that leaves the option open that it may be it may be finalized um as well and agreed that only once

it's finalized on the L1 you could could call it finalized on the um L2 be all-encompassing um question have people had the a chance to to take a look at this or would it be helpful to just briefly walk through um sort of like the the um the most relevant ones I think the first four are around to be straightforward but maybe the last three or um is that not just asking would be if it if it were helpful to do that I think as long as we um time box

this and basically not have have it be too long I think I think it's actually it might be helpful if you briefly um go through Maybe just the just the last two um so it's it's which are I think that's where was was most of the discussion was around there um because it's it's if it was included in the L2 again could be finalized let's let's do this just the definition so it's L2 included L1 pending then the definition is an L2 transaction includ L2 block but not yet submitted to the L1 um the trust assumption here is that the L2 inclusion guarantee is dependent on the submission guarantee of the L2 block to the L1 the L1 finalization um as a transaction code um basically l l2t z 500 so have a little

little room to grow um and people to use other transaction codes wanted to if there's if if they needed additional transaction statuses in addition to those not placing those um then the next one is L2 included L1 included which is an L2 transaction included in an L2 block included in an L1 block that is L1 finalized just assumption is the L2 inclusion guarantees dependent on the L1 block finalization containing the L2 block um and then the last one is uh L2 finalized L1 finalized then definition would be an L2 transaction

included in an L2 block that has been included in a transaction and the finalized one block first assumption here is the L2 transaction finalization guarante is equivalent to an L1 transaction finalization guarantee in the finalized L1 block and then there are some requirements around um just that should be transaction code must be an alpha numeric strength and a um testability statement that's just a requirement for the for the specification which I think is is a good practice by the way if you have a if you have a requirement in his spec you should have a logical test

there um yeah so it's it's uh you wait for for for final um yeah go ahead Anar yeah um um because I also wanted to to address with Elias's question and and it's actually it's interesting in this context so indeed the kind of the the question of course of um L1 inclusion and then finalization and there is actually um an in an additional con cont concept now on the L1 which is work that Franchesco has been doing um together with some other collaborators in the past um around the confirmation where basically it takes some it basically you

could think of it as some sort of like optimistic finalization where it it looks at the um attestations as they come in and and basically under certain circumstances and you can basically set a safety threshold already con can consider a transaction um basically optimistically finalized or basically it's kind of locked in and it won't be won't be Reed anymore once it hits a certain threshold and that would be the hope would be that like because right now often times exchanges and things like that they still um just use a number of blocks um as as the de facto kind of um standard for for confirming transaction because the full finalization of A1 is relatively slow like 12 minutes optimistically even in

best case so so this the hope would be that this new confirmation rule could basically be the Best of Both Worlds where it basically is fast but actually is like more substantive than just waiting a few blocks and that is not yet rolled out in any clients but it's something that I think would be worth paying attention to although of course it's not super relevant in this layer two context I mean or rather maybe that that could be a question to to Andreas like my my understanding would be that most of the time this kind of status seven that you have there L2 finalized or one finalized um the the time constraint The Binding time constraint there or like the the the thing that comes later is usually probably the L2 finalization anyway right like the only exception I could think of would be like

very fast proven um ZK um l2s but so far I think that's not not the standard usually they take they trailing a little bit in their proofs anyway so I assume basically speeding up the um to basically replacing the full L1 finalization with something that is more something like the confirmation rule um um optimistic finalization would probably not actually change much right because you'd still have to wait on the L2 finalization part of it right yes yeah correct so the these could be um additional codes that are in you know if if that optimistic rule were introduced you could you could still you one could add um um additional Cod um um additional codes here right but before

that exists and is there I don't think it makes sense to to um to do it and the spec does not exclude um different clients to to add additional um to add additional uh statuses in between that are you know uh um depending on on how they're how they're structuring it what the what what type of Da they're using Etc right so the the point is that they're trying to to leave more room to like sandwich in additional codes become

relevant and also the the the status codes give um fairly Liberal Liberal space to to add um additional additional transaction codes um I haven't looked at the the latest one so just always um uh hen you um feels a bit too complicated to include the L1 block finalization

status um well so comment to that is if if your L2 can be reared or or there there's the possibility that the that the L2 can be can be reworked then it's it's it's really important to know whether the l1's finalized because then the L cannot be reor anymore so if obviously if your client if if if the L2 is is is is finalized and it's just even if the l1's rearch you're just resubmitting the transaction that's one thing right um but if it can be reor depending on on the architecture I if you have like optimistic rollups then um

with disputes resolution Etc so that that that's a a possibility um yeah I kind of like I agree like so so the main point is that uh so Layer Two has it's different status for like whether you submit the data to whether like first they included the transaction in the layer two blocks and then whether this transaction has been submitted to the layer one for the da and then whether like the finalization has been uh set on the layer one uh so they're like the kind of three to four status for the L transaction alone then if you multiply by the layer one status like it could be layer one block finalize or not then that kind of like it can you can

grow from like the four status like to maybe like 12 or eight or 12 status I guess but that's dependent on your client right so that this is if if you want to include them right so this is sort of like the minimal set right if you if you have that that's like the minimal set that should be adopted if there are additional statuses that that your client has sure it's like add them right um it's like you can sandwich them in in between the different the different statuses it was just sort of like what's sort of like what what is the minimal set of statuses that that everybody will have in common just to to to give to give at

least um a more structured uh framework for for um for wallet and and um uh and users I guess I can maybe have a quick CL clarification question on between six and seven it's like that so it's like L2 included and L1 included but does do you need that the uh the transactions are submitted L1 that includes Layer Two transaction data uh and then that L1 block does that like require the L1 block to be finalized or not not because I think like on on the seven like you require this like transaction uh to be included in the

finalized L1 block uh so included means it's it's not yet it's not yet um um L1 included just means it's it's included a block but hasn't been finalized yet you haven't waited the the um so you have a super majority on the on the um um you have two super majorities on the um on the link right so the 12 minutes um the the L1 included just mean that it's it's it's you you you have submitted it it may be reor likely not um but if it is right then what happens it's like you

you have does the L2 have to resubmit it and it's still in the L2 block or are you going to actually reor um on the um L2 right um because now you're you're you're um your your your your sying is off right may not yeah so yeah that's like that's like the my main question is like to this like do you want to have like L1 included and L1 finalized as a like 6.5 status here um well if it's if it's the if it's the um if it's what you'll have the the the transaction

that D2 transaction that points to to the block that contains all the transactions I mean there might be additional ones so it it again it depends on how you are how you're doing your your um your sub of the of the data do you do you do your commitments to the batches um on the L1 and what happens if they are in in different slots right so if if you then then you you can't and if that gets rearch then you really have to rearch your um L2 block but if you don't do that then it's then um you don't have to do do reor on of the L2 so there there are a lot of nuances in in between six and

seven right this is just to say it's like hey this this transaction this L2 block is is is is included that's like done and it has been um uh included in an um in a slot on on um in an Epoch that's it right it's it's it's not it doesn't make any statements about you know have you sub have you submitted batches before that are that are now that might be in in in previous slots or not or is this just your state Delta that you've submit with one and you know everything is now and which everything else is is is in Blob space so

there are many different approaches here that the different clients are are are taking just between you know between sta 6 and sta 7 so um I think they're basically just a the the goal posts so to speak the sticks they um uh um as they say and there can be like a whole lot of other um different nuances and status in between if clients want to give more detailed and granular information as it may be relevant to the to the to the different different product that are that are running on that L2 I don't know whether that that that

answers your question or your comment yeah I think like I kind of get it so one followup question is like you don't I mean you were just deem like the this layer two transaction is finalized as long as like the the transaction data is included in a finalized layer one block that is like de as the a finalize like that is the state seven so like for any like for the SEC Ops if the the ZK proof was submitted to the to the lay one that

doesn't make any changes like in this transaction status is that correct when the proof is submitted with the with the um that's the that's the the proof submitted and and and and verified then then um and that transaction is is um is then in a finalized block then that would be status 7 until then it would be um statistic yeah okay yeah I probably like

I'll think a little more like to give some more comments yeah give give give comments I put the link in the in the chat this is not done yet right it's like we're we're we're really um eager to to to get more feedback um and you know there's there's also there's there's there's an issue also that that's related in the um in the repo you can um that points to the east magician post if you want to post there you want to comment directly here on the on the um um on the pr please do right I mean this is this is not this is not not yet in stone we we're you know um we're trying to get as much feedback um um as

possible but I think it's important to have at least some goal post there that that are um that everybody can um can agree on uh I just have like one another question like this just speaking for other zups like when they submit a state diff uh how does that change like is that also you thinking like a similar to the like the definition of six and seven the state diff is is exactly the same it's like that it it it fits in right I mean it's it's it's um you're you're you're submitting what what exactly is um is in that what exactly your your the data is that you're submitting um as to

as to the L2 State and um what the what the proof for for verification is is not really relevant I mean it's relevant for the client but it's not like for the transaction status it's not because there's just the goal post right posting do you want to um do you

want to uh say something with regard to stet yeah I don't know ordering in the L2 block is is um that's really I mean that's um um that's um relevant but I think for as far as the status here are concerned it's not it's not necessary to um

consider um I mean what could what obviously what could happen if you if you if you have a if you have a reor on the um L2 so there's a there is a question what happens if you're if you're um if you if you have a um if your consensus on the um uh on your sequencer is slower than the consensus on the on the um until L l1's finalized right so where you could where you could have a rearch on the L L2 but but the L1 is actually faster in the final station that would be a problem

so again this is this just to to to start the discussion to to get things going to have the client teams think about it and see if they're if they're um how how they're fitting into this um into this proposed framework so um uh any more um any more questions oh yeah on on between sorry see the

discussion in the the um in the chat about you know what's if you have confirmed whether that's like confirmed with ordering or not so I think that's um I think Ana what do you want to do do you want do you want that the the the discussion on the right on the chat yeah so I was I was I was typing typing as as

you as you ask this uh so basically yeah I think um my understanding is that you also wanted to to um to to to schedule um with with people in this group um some some future calls to dive more into this right so then I would I would say it's probably better to keep it for now I think there's also one other topic you wanted to summarize as well if I understand correctly so so maybe otherwise so that we just keep it somewhat time box maybe best to move on for now then and also with these calls it's better than people know to show up if they're interested whereas like here if we spend too much time and then some people maybe missed out on it would not be idea right yeah I think I think we should we should just schedule um maybe for for for next month or or later in

the month a um a breakout session for just that particular topic I think everybody would that there there seems to be enough um discussion potential to have something dedicated that it's then also also um you know properly um advertised that that's specifically for that yeah I agree and just um just to say um I'm not sure that right now KL and I have the um ability to like necessarily um at least commit to kind of co-hosting such a call so so maybe I think it would be best if we schedule it more like as kind of a call led by you

yeah yeah use to advertise it um but have it not not like I don't want to commit yet to like you know it being necessarily part of the the the the r call um directly but but I I think it doesn't really make a difference um yeah I mean it's like it's like doesn't matter who's who zooming Zoom link we're we're we're using right yeah exactly exactly just wanted to mention it yeah yeah I'm I'm I'm I'm happy to host that not a problem right we just need to coordinate on a um on a date so maybe in two

weeks 25th we don't have that many people on this call right now so I could imagine that it might be a bit hard to try to do life coordination on a on a date and no no no I know I know it's like it's like what I'm saying is like should should we advert just advertise for um for for it to be a dedicated breakout session in in two weeks and then we'll just we'll just put it on the boook yeah I think that seems reasonable to me okay good cool I I'll send you the the the zoom link over we can do same

time, 1400 UTC cool okay and then there was one more topic you also want to talk like adjacent topic here right that that yeah so so yes correct let me um Let Me Wait a second um yeah um so the AP the API um share so um we had that and sort of like

um has been cooking um a little longer this was um um a transaction fee um API spec based on on the um transaction fee um back that that um the L2 working group did earlier but um um it's just the the the um we um had and had shared um like two um two schemas for for um a um a post and a get so in order so the first um the first uh spec here is for

for um as a post um and it's for an estimate so what's your what's your um what's your uh what's the estimate for an L2 transaction fee and then um basically the the inputs would just be the the the transaction call and and the chain ID as as required elements and um where the um you would basically just have the the um as an object and required is only from input and the value um and then um additional they their additional optional optional

parameters here which is all in line with with um with um uh what currently exists in addition to there like three things which is um the TR priority um the currency if it's not if it's not um if if if clients allow for that be priced differently than just their their their native protocol token could be even in Fiat um and uh so transaction priority if they want to if if estimate is for for particular um uh priority uh than currency as I said and then the chain I as a as a

required one so it's it's clear that was actually meant for that uh client and not for another and the response is basically um just has has three elements the actual execution fee the data fee the priority fee and then the total and um just to to uh um give one example for example the execution fee has um has uh um a value for the currency um the gas and then the price um they're optional there some optional

parameters um in there um as you can see besides the uh value the value of the gas and the price itself it's the um uh al2 gas gas price derivation method and um the um al2 price derivation method Source um so it's just to to include to make sure that it's clear how how that that price is is um um is uh derived that and that is um so for the this is was just the example for the execution fee uh it's the same for the data fee

and the priority fee uh except the priority also now has the priority status that as a as a Str um any questions on the on the um on the um on the estimate transaction fee estimate um transaction yeah so there the the we discussed the the the different derivation methods and it's um yeah it's done it's done differently the the um especially the the the data fee um is

has has a lot of different components you know depending on what the what the different different uh um what da is and so forth so the definitions are broad enough that it it encompasses the the um all all the different all the different variances and that's why the um why we included the um uh why we included in the responses the derivation method and description um uh and the source as a um as optional parameters in order for for for clients to be able

to um uh publish out um directly their their um their details so people can see what the differences are which is by the way also required if you're actually you know have clients that are for example in the US um that's actually a legal becomes a legal requirement because of the the the uh us regulator the FDC requiring feed trans transparency but that's just as an aside uh

no but it does not it does not preclude that alah so um so it's not it's it's you can you can um um you can obviously you can add additional um um additional um elements to the to uh to the objects um uh and I think if it's if it's if it's required that that um this is going to be priced out uh um like differently then obviously we we'll we'll introduce different

different um gas types does that make sense and again this is again this is open that's why we want um uh that's why why we want um like feedback here right what what what do we need to do

um to to get that um to get uh yeah as you said to get to get to get byy and what are the and they they actually the the so both um members from both from from from um arbitrum and and optimism have been participating here and putting this together so um um sort of like a a currently minimal um minimal level of agreement but again it it would be good to actually hear directly from the from the from the client team lead

um what that what that uh would be so again I would I would um calll it would be good to have a to have a breakout session for this yes so I was about to jump because also we are about to end to to to reach the hour of course the call is scheduled for another 30 minutes but from experience often on the hour a lot of people have to drop so just to understand you would you're you're trying you're going to you want to host two separate calls like one on this other topic and then one on this okay and did you have a um date in mind for for for this one as well uh um we could do it so we had the 25th um we could do do it like um what

you like a week later October 2nd or a week early or that would be one one week give people a little bit more time like October 2nd or October 9th well October 9th if you at least want to reuse the uh roll call time slot then of course that would just conflict with the next roll call so um October so then then I would say should we do like the the second or the 16th what do you think um I I I don't I don't really know like how how much overlap This and like between those and so basically how much extra preparation time you think people will need um I would kind of leave that up to you I think either works really

honestly um okay yeah I think I think maybe give it give it a little uh um a little more time like uh for this for the um for the um for the um API so let's do the 16th then okay sounds good okay great so um we'll coordinate um I'm happy to host the you know both of them on the the 25th for the status al2 transaction status on the 16th for the um API back that's good and did you have um I feel like there was something on an IP

as well or was it was it already basically um was it this the Bally this as an IP or or something something separate or um oh no this is the other one is the is the sort of like the definitions of what a what a what a data fee is uh execution fee priority fee that's a that's a that's an RP but we're we're out of time okay yeah yeah yeah then and because then I would probably want to briefly just go back to the kind of the the other topic that that Max asked me to bring up and then wrap it up if if that's okay with you or last year no perfectly fine well then thank you thank you so much for um leading this this this part of the call um and then yeah like so so so last

topic um max unfortunately um wasn't able to to make it today but he asked me to briefly mention so there is his proposal to basically increase the minimum price that a um blob uh costs on uh mainnet right now that is set to basically uh one way so um or at least there's there's a unit of of blob gas and that's that costs one way so basically the price of a blob right now can go all the way down to basically fre and that's indeed where we currently are in the equilibrium because we don't yet have enough demand to actually um go beyond that so right now blobs are basically free um which is not a problem at all but the um the problem arises every time we basically have demand

spikes that get us to um now the market price would want to be above fre and because uh because of the kind of the feed feedback mechanism the 1559 star feedback mechanism that the blob also um uses and that just takes some time to to ramp up to a new equilibrium price Whenever there are like big changes in in demand and because it has to come from such a low level it basically takes um a lot of time I forget the exact number but it's uh it's like I think half an hour or something to to basically get to some any any normal kind of non non non totally free price level and so for like half an hour there's basically just no efficient pricing and so you always for back to these her fee auctions which have the additional um drawback that um with blob

transactions specifically they are a little bit more complicated because they're measured in normal gas not plop gas so there's some some some issues around that anyway it would be preferable if these ramp up times would not be so long and so a Max basically proposes that um in the next hard fog um and my feeling is that would be part of the basically the first half of pectra no matter what so that would basically come soon we basically just raise the from Bas from completely free to something that is basically effectively still kind of free so it's not it's not meant to actually raise any Revenue it's not meant to actually cause any strain on any of the layer twos it's really just meant that to be as close to this kind of the sensitive price range as possible so that in the case of a demand

spike it can basically ramp up more quickly of course this will no longer matter once we hit sustainably hit at least the target throughput level for blops but given that so far in over half a year we have not done that yet on mainnet the idea is is let's just chip this just in case because otherwise we keep having these kind of occasional 30-minute Windows of kind of price chaos um now Max wanted to specifically ask feedback um I think let me let me let me um oh I just see my my my great timing my Chrome just crashed um let me actually uh I don't I don't know where is it uh sorry second let me look up the exact number um that Max proposed so basically he had he he

figured out a number it's I don't know 2 to the 25 whatever um but specifically that would come out so that um blobs would at a minimum now always basically cost at can't e prices more or less 1 cent so basically you could imagine if a blob transactions come transaction comes with four blobs then would basically at least cost four Cent what plus whatever um um it consumes an execution right which is not affected by this change um of course if the E price say 10 X's then the minimum price now would B effectively be be 10 cents um this the idea was that this is chosen low enough that it really doesn't actually you know effectively influence the uh Layer Two U transaction prices at all um but be

basically like high enough so that you know it doesn't have to to to to um go to too many kind of orders of magnitude to reach a reasonable price range once there's such a demand speik now of course the concern is if layer 2 say that this is still a little bit too high say maybe I don't know those 1 cent per blob is a little bit too high for use case or something you'd rather see it a bit lower um or of course the other way around you think it's a bit too low and it still has a bit room to to to be raised to be more sensitive to price to demand changes um now would be a really good time to to give that feedback because otherwise probably the EAP will start to move forward and and um it's always harder to change these parameters

once thep is accepted so um of course either if there's um where we can find more information about this there an let me yeah that's a good point again my my microme crashed in like the worst moment but uh I found the link so this is the link to the EIP draft um I think in the rationale there's basically he he reason Sue all these kind of specifics around the the pricing um yeah so I'm just wondering again like we have very few people now but many people are ready to drop if anyone on here already has some specific opinion otherwise of course if you know you can you can talk to your team or if if someone SE this recording um just basically um contact us write in the roll call Channel or reach out to Max

Resnik directly um that would be really appreciated feedback so um if if anyone has has has something right now um yeah I wasn't wasn't assuming that so then yeah then just as a PSA and uh yeah do do let us know if if if if there's if you're very opinionate about this okay um I mean of course we always have an open section at the very end so is there anything specific left that we would want to talk about today otherwise we can we can end the call okay then well thank you all very

much for showing up today and uh see you uh either on of these uh Andreas uh calls oh I guess we will only have one until next R call or then um next month on on next R call bye everyone thank you by thank you