RollCall #8

Transcript

hello and welcome everyone to roll call number eight um that's issue 1170 in the ethereum PMS repo um I'll drop a link in the chat uh as usual will be recorded So for those who can't make it can check it out after the fact um today uh let's get started with a presentation from uh Wilson I'm sorry I'm not going to attempt to butcher your uh your last name um on rip 7755 um hand it over to you yeah Wilson qac from the base team do you mind um letting me share

screen uh sure one sec might be a ethereum call PHA to have your video on but I like people to see me no it's great okay cool here we go so I'm going to share this screen there we go we got some other videos on all right so yeah thanks for having me today uh Carl thanks for uh inviting me to speak on this um so rip 7755 uh this is uh the title of the pr currently is contract standard for cross

L2 calls uh and and the sort of brief is contracts for facilitating the request fulfillment and fulfillment reward of cross L2 calls um the first thing I want to call out at the start is is this is very much under construction this is currently just a pull request on the rip repo this is not even in draft yet um for example uh we could probably make some changes already contract standard for uh instead of calls maybe requests um the toic had a comment that calls is may be overloaded and then it actually could just be generically cross chain as as we'll kind of get into um so going to take a few minutes just to kind of run through how this works hopefully it won't take too much time I'll have some topics for discussion and happy to answer any

questions so the the goals of this was a low-level specification allowing arbitrary kinds of calls um we wanted something that was maximally onchain and so as much as possible uh sticking to ethereum and the related chains and what is uh sort of intrinsically available on chain and then a sort of batteries included proof system with minimal trust assumptions and so some of the context here is that um I feel like a lot of people are working in this space and I kept on sort of hearing proof system agnostic proof system agnostic and then uh I I didn't really I could it was hard for me to understand what actually was the preferred proof system with minimal trust assumptions um and then in talking with some people about this we realized that in the context of l2s or really any

chain posting EST state route to L1 uh we can actually deliver something with pretty good trust assumptions as as we'll see so how it works um call requests and fulfillment so the idea is you have some origin chain and a destination chain and you have a user who wants to make some call on the destination chain and to do so they call into this cross chain call originator contract and in the pr you can see the specification for this but basically this is the struct that specifies a cross chain call so you have an array of calls that you want to make with to data value you have an origination contract that you're calling into and that's on the origin chain orig or chain ID destination chain ID Ann just to distinguish this from any other call

that otherwise has all the same parameters a verifying contract so we'll talk about that in a minute um the contract that's going to be used on the destination chain uh as the source of truth that these calls were actually executed uh L2 Oracle we'll also talk about this later but this is uh where you expect to find state routs for this destination L2 on L1 this is an address and in that on that L2 Oracle the specific storage key at which you expect that uh uh route to be located and then a reward asset a reward amount um these are specifying whoever fills this request and can and show that they fill that they're going to be paid this and then a finality delay seconds and this is a finality delay not on the

Fulfillment on destination chain but on a delay for the reward being paid out and so this is in the case where you want to uh have some guards against the fact that um you know some of these State routs might be pending realiz this is a lot of uh context right out the gate uh we'll get through this and hopefully it all make sense so you're you know doing this cross-chain call orig originator and it's emitting some event somebody you know has this desire for this call to take place and we can kind of you know draw a boundary of what's onchain and offchain here so offchain there is some you know filler that is indexing these events and decides that they want to fill this request and they call into this verifying contract on the destination chain and the verifying contract does some you know basic check to make sure

that you know this is the right chain ID uh that this is the right verifying contract for this and then basically it's just going to iterate through all the calls that uh were asked to be made and if any of those calls revert then this whole call is going to revert but if all the calls succeed then it's going to store this info um and so it's going to say fill this uh this uh for this call Hash it was fulfilled that this timestamp and this was the fulfiller and this is what we're going to prove stayed against later so the general idea here is sort of uh we can get you know really nice um trust assumptions using storage proofs and in fact as we'll go through the mechanics of you can sort of prove State on other l2s using recursive proofs and so the challenge is just we

need a state on that destination chain that shows whether this call was made or not and so this is our record uh that this call was made and it has some analogies to you know the withdraw flows for l2s generally where you're um you know have some state record and then you're proving on L1 that this state record does EX exist on L2 showing that you you made a withdrawal so uh the filler you know uh calls here and then those calls are are made out as as I sort of describe sorry did uh the call just jumped am I am I still on the call still the call but screen sharing off okay let me share again sorry I

think it just exited me and rejoined quickly all right can you share my screen screen again or you see my screen yes yes yes okay you you could see it before correct I wasn't just talking yes no we could see good sorry okay let's keep going so um then how reward payment works so ideally both of these Destin this origin chain and this destination chain are writing to uh some shared layer and we can call this ethereum L1 and this is why I say um it doesn't have to be l2s right technically this could work for any chain that is willing to post its state route to L1 so it could possibly work for all kinds of chains so if this destination chain is posting a state rout to L1 and the origin chain is posting a state rout to L1 ideally also there is some way to get the state

route for this uh L1 on the L2 and so uh you have some block has Oracle or some trusted way of getting uh that L1 info and with these ingredients you can uh construct a storage proof um and and it's sort of going to be a a nested storage proof and so we first want to use the L1 State roof to prove that there is uh some State rout on this output Oracle contract um or or state root Oracle contract on L1 so we want first a trusted state route for Destination chain and we use our state route for L1 to get a trusted state route for Destination chain and then once we have a trusted State roof for Destination chain we can go on to prove uh whatever state we want on the

destination chain and in particular we want to prove something about that that verifying contract and so this is you know these parameters that I described earlier you are saying you know the the L1 address of this um L2 State Route Oracle and the storage key where you expect these to be uh I'm just going to keep going and and we can take all questions at the end sorry if if anything's been consu confusing so far I'm happy to happy to hop back but basically the filler is going to post this nested State proof into the the cross chain call originator contract and they're going to be paid out that reward assuming that state proof checks out um so some frequently asked questions how is this different from ERC 7683 um

the ERC 7683 is is more about high level intense uh versus low-level calls we're trying to specify exactly the calls that we want to be made here rather than the outcomes we want also as written ERC 7683 is currently focused on swaps I know the team has has some desire to try to change that um 7683 is proof system agnostic versus this is specified and importantly this uh system specifies sort of onra uh origin contracts specification so you're assuming that users are making this request on chain that they want these calls to happen on on destination chain um how is this different from op stack inop and again I'll just say I'm talking through these I'm I'm not I don't consider myself an expert on any of these so I'm happy to be corrected um so interop allows faster

settlement without compromising trust guarantees so in the system I I described you would have uh the filler sort of is like you know taking their own risk if I see this request from origin chain and I immediately fill it destination chain I'm taking some risk that you know origin chain is going to be reorg and that is that reward is never going to be paid out the user can sort of specify their tolerance for risk on destination chain uh you know some fault proof or whatever there by uh calibrating that fin uh finalization delay seconds and so if they want to wait seven days they have a way to to express that so inop um allows you to sort of tightly couple chains such that if you know you can specify how far you

want to uh trail behind head on a given chain and um uh if that other chain reorgs you are also going to reor and so you could sort of have immediate fulfillment in both directions um and and trust that if one of them reorgs it's going to reorg on on both sides one of the downsides of interop is it requires a dependency set and so each chain has to specify the chains in its dependency set and all those chains sort of you know uh they're dependent on each other and that that's a a challenge and I think that if we're headed into a world of thousands of l2s you know is that really going to scale so I think this is is possibly a bit more scalable um there's a question of how do you solve race conditions where you possibly have many fillers that want to fill at

the same time one idea that we have is some sort of exclusivity period and we can generalize for this by saying that on the destination chain uh before you fulfill the struct could also have some pre-check address in a pre-check call data to call and this would allow for arbitrary pre-checks to be described and one of those pre-checks could be you know an hour or something where there's a specific filler that's allowed to fill this and then after that it would be open another idea is to try to leverage ERC 4337 because they have similar CH uh challenges that they're trying to make a um a global men poool and you know there's this e send raw conditional RPC that's being used for a lot of the uh user op mol and possibly if you imagine that the um the

Fulfillment contract on destination chain is actually a pay Master then you could sort of um fit this into that system finally what is the sort of contract change proof system relationship uh you know how many what's the many to many so on each origin chain as it's currently described on each origin chain you would need one contract per proof system and so the proof system is described there and so uh you know you could for all op stat contracts um they presumably would share the same proof system uh and and you could uh you know describe those all together uh you know maybe arum could fit in there as well if arbitrum needed a slightly different proof system then then you would need a different uh origin contract uh but that brings up the question of you know should the proof system be abstracted and I'll get

to that in in the discussion so before discussion how can you help uh leave feedback on the pr check it out um consider for L2 specifically consider how we can standardize the pieces needed for proofs so for example it would be great if we all had a unified way of uh uh exposing a trusted L1 block cash or a trusted L1 state route on on L2 uh this currently does not exist all twos and is a challenge um we could consider standardizing where State Roots live on L1 you know uh describing like some Reserve storage key that state roots are are stored at or in particular a way of describing um a consistent way of describing pending versus finalized State roots on L1 so for discussion you know we've been

discussing a lot of people there's been some interest in this and some people are happy with it just as uh sort of a lower level way to specify the exact calls that you want to make and to spe specify desire to make calls on chain and uh there's a there's a ask of whether we should keep the storage proof system um a bit separate and possibly not have it in this rip um there's discussion on ways to leverage ERC 4337 which I kind of alluded to I don't want to take up too much time and then we can discuss any other questions you have I hope that uh made some sense uh yeah go ahead

Andre um several several several questions um but the the immediate one is um if um your request just sits there and is never fulfilled or is not fulfilled for a long time the state obviously changes right on on both the origin and the destination chain yeah so at what point would would is there is there a way you you you can fulfill a Max duration for which this this request uh is okay to be fulfilled you know especially if you're thinking about like your your you know you you want to do providing liquidity for for certain

um for certain for certain transactions on the destination chain that's time sensitive and it doesn't go through then it doesn't make any any sense to fulfill the call so is is there is there is is there sort of like a an expiration timer um yeah it's a great call out it's something that's it's been called out on the on the pr um it's it's a change that I haven't made but I'm intending to make that you can um describe an expiration and something that is there uh currently but I didn't go over is that you can also request a cancellation and so um On the Origin chain you can request to cancel and then there's sort of a

waiting period whatever your finalization delay was and then some uh guard additional waiting period for somebody to prove that they made the call and if that period passes then you can sort of finish finish your cancel request um but yeah great great question does that does that answer it yeah yeah yeah um absolutely I let others go question I don't want to H okay let's see I don't know if we have others so you're you're welcome to ask more if you have them no there's a question in the um oh in the chat sorry let me see on state Roots you're building the cross chain calls upon how do you make sure they're not Perma sale because you're checking on L1 the state rot of

other l2s but as soon as it's posted and L2 State Route is almost already stale um so the the storage proof is constructed against a specific State routee uh and so all you need is the specific state route that you were um that you Ed to construct your storage proof the bigger risk is that you know there's some fault proof or something and that State Route becomes invalid and so that's sort of up to um you know the the uh user to decide their finalization delay that they want for that if that makes sense ises that does that answer your question allies um yeah Eliza I don't know if maybe uh

you want to unmute and describe your [Music] question you're checking on L1 you are proving you're proving using the L1 state route that some other L2 State Route exists on L1 and then you're proving using that other state route something about that other chain this is all happening atomically in a single transaction hey sorry um I I was getting to another room so that I could speak

and then uh everything broke sorry my okay all good no I was I was saying so my understanding is you're you're checking another L2 state route on L1 right you're constructing the storage proof but but but that state route as soon as it's posted on L1 my my understanding is the the the L2 is going to construct new blocks on top of it as soon as it posts it on one so how do you make sure you're not kind of Perma behind on on this St you don't care if you're behind because pres uh all you care in this case we're trusting our verifying contract that that state exists and you know the verifying contract is not going to allow that that specific state to change at Future blocks so when you construct like an an 1186 storage proof you're

specifying the specific block that you want to that storage proof for the specific state route that you want that storage proof for so it would be a problem if like the call could happen and then somebody later could reneg the call or something but the call is sort of it happens and then it never happens again it can't you can't take back the fact that the call happened and so all the user call cares about is the fact that the call happened I I still understand how like if if if maybe like at at State rout a um you have a balance on a rollup and then you want to do a a cross chain call yeah so so it would be a problem if we were proving specifically like prove

that I have 20 die right that could be easily manipulated but we're not we're proving a very specific thing on a contract so you specify the verifying contract and um let's go back to that code right this this storage record is it's a very specific storage record that's being written it's a storage record that these calls that you wanted to happen happened and so you can't take back the fact that the calls happened if if the user can sort of be griefed here it's kind of their own fault they they specified I want some call to happen the call happened now they need to pay the reward but it's not like prove that I have 20 die it's prove that you made this call that I wanted to be made okay so you commit to an

intent and commitment is very loaded loaded word so I'm not sure I want to use that one you're it's a very lowlevel intent if it's an intent you're you're specifying to the value of the data that you want to be called and you put this into the state such that you can construct a state Roo of this oh sorry State searage proof yeah you specifically you use a verifying contract uh as sort of this pass through contract to write a record that this these calls were made and at what time they were made and who made those calls this ALS Al allows for you know you can't doubly fulfill a call um if it was just 20 die two people could prove that I have 20 die but here only one

person can ever fulfill this request why because the verifying contract is specified in the request and the verifying contract ences that the call can't be filled again the call is already fulfilled here okay um and so there's no expiration because you say that you're building this on top of the latest L2 straight route expiration would be a good thing to add as we just discussed so I think you know having an expiration on the struct you could also check and fulfill whether this this was you know expired the user doesn't want this to to happen anymore but you're saying it's not a

problem move sorry oh oh sorry State Route expiration yeah State Route expiration is not a problem because because all I care is I trust this contract if this contract says at any block height this call happened I know because I know this contract that it's never going to unhappen you can't change the fact that these calls happened so in the case of a ZK rollup you're saying as soon as you settle a state route you can never go back on it and and okay and and you also count that L1 does not reor yeah so again there there is this ver there's this verification seconds

that can be the finality delay seconds where somebody can specify the age that they want to have passed um and they can dial that that parameter for themselves is that is that in seconds or should that be in locks on the L1 I think I for a seconds but open open to debate it no I was I was just thinking because you wanted to um you know if you're if you're if you're specifying like like an Epoch I mean let's let's just stick for for um ethereum right if you're if you're if

you're specifying that you know because what once once once the transaction once the route is is is in a finalized EPO it's done right I mean you can't that that can never that can never that can never reorg right so it's like you have a you have a you have a maximal uh delay for which the the the um you can have an L1 reorg right you can have an L2 reorg um in principle but that's yeah the L1 block this is really about the other L2 I'm I'm trying to guard against the fact that the L2 might have a reor fault

prooof and so I'm using the L1 block as a proxy for how old that State Route is for that other L2 oh okay okay oh so yeah okay if you have if you don't have if you don't have have um um if you have if you have fraud proofs yes but then you you you need to like have like very long periods because because your your your fraud proof periods are so long possibly it's sort of a tolerance thing I think it'll be priced accordingly you know we I think this will probably be mostly handled by wallets and stuff they'll abstract this for their users and and pick a risk tolerance if that makes sense yeah I know it's like it's like yeah it's just

thinking this is really just a just a just a standard for for for basically the the the the overall execution pattern not really for the under that the that the calls are actually uh um that they're sensible there there needs to be another Network that where the lowlevel call the the lowl calls that are actually being made or or or verified so there has to be in the calls that has to be approved that for example you you have you have 20 die locked up on the on the on the on the origin chain that you want to move over to the destination chain yeah yeah for example I can there's a somebody recently did an example where the case where they want to send some die and in

that case the call you're describing that you want to be made is actually a call from the verifying contract to wherever you want the Die to be sent to and so the filler in that case has to pre-transfer some die to the verifying contract and then transfer it it on that's one way to do it uh if you look at the pr there's some discussion on different ways of like where where could assets be held um well you need to you need to lock up on the on the you need to lock lock it on the on the um you need to lock lock it On the Origin chain and then once it's it's it's fulfilled on the destination chain right you need to burn it on the on the

um um On the Origin chain right there there's a reward yeah but they're they're not necessarily tightly coupled like I the reward I could I could pay my reward in any asset I I might be M trying to make oh yeah yeah the reward you can pay in in in any asset yeah of course but it's like it's like that's that's and it and it could be paid on any chain in principle right I mean you could say I'll I'll I'll pay the the um I'll I'll pay the reward in in in Soul even if you wanted to right I think so because yeah the reward needs to be by this specific contract where where the request was was

made um I do I apologize I do uh I only have a few minutes left another meeting I have to hop to thanks again for taking the time sure if anybody has any uh any final question I'm happy to answer it uh yeah one quick question not a question actually but more like a suggestion uh on the delay would be nice if you could um specify some values like wallets have been historically not super good to make like opinionated choices in this situations so like Ju Just some boundaries of like what you consider and so would be nice just to give an indication to the wallets yeah and again it would be cool if if L2 is aligned on some of these

like canonical ways of describing pending versus finalized State because then people could just specify a binary of like pending or finalized um but yeah that's that's a good suggestion and thanks for your presentation yeah thanks everybody I really appreciate your time uh please check out the pr and and and comment and uh please uh if you have thoughts on some of these discuss sessions feel free to reach out to me I'm just wilsonc on on Telegram and on Twitter and so happy to chat and thanks Carl for inviting me in and uh yeah appreciate it great thanks for uh running us through your R great um okay next topic for

discussion uh some 01/ pectra updates I'm in Hand of the onar those sounds good uh yeah hey everyone um uh like last call I created a presentation although it's even short it's just one slide but I always like having a visual reference so let me just briefly share my screen can you see my screen yeah looks good yeah awesome yeah so basically the main update that I wanted to give is just specific specifically uh on the last roll call I mentioned that there was under consideration potentially come splitting the upcoming pectra hard forol on a one

into two parts and that has indeed now been decided um so basically there will be two basically two parts of the pector for but um because of naming consistency the first one will be called pector the second one will actually basically get the next name in line which is called faka um and specifically basically in in terms of like how the split falls out uh you can you can refer to the meta EIP 7600 if you want to see the full list of um features for the for the Petra for but in particular the relevant for um l2s as well of course are mostly the evm changes uh that that then um you have to make a decision on whether to also bring

those to to your um l2s um there are several also like for example BLS which is not mentioned here but the the main one um is uh e 772 so the the set EA account code one that one will be part of the first the basically the of the pecta side of the first for and and then I just wanted to copy again the recommendations from from last time um because of course that that now is locked in to to to happen relatively soon um so you should really basically have a strategy around this is this something you want to support um at the time it launches on one are you not going to support that for now um that depends a little bit of course also on on on the wallet situation and maybe

reach out to some wallets um make make sure you have a strategy um and in particular also given that uh the recommendation for 7702 is that uh wallets basically use it to um have a 437 uh compatible uh smart account um delegated to from from an UA um it would be important that your chain works well with uh for 37 um and then one more point on 7702 is just if you say curious but want to play around with it a bit or something to basically just get a better feeling uh one Shing point for that could be that they is planning to have a shortlived 772 specific test net around Devcon also

for hackers at hackathon and everything to basically play around with so that could be relevant if um for you um and then the other big topic on the the basically the first half side and that is related to the fact that um as you can see further down pias actually was decided to be pushed into the second half into the fusaka side of things so there will be no kind of Big Blob throughput increase coming by pus yet um in the first half but there is now the question of whether we might have some room just using the existing architecture the the thing for before architecture to basically give a little bit of extra blob throughput um and so in particular basically right now we are

like an average of three blocks per block and the question is to maybe push this to four or five or or possibly six um so basically that that would be still a good kind of super increase that is not certain though um right now we kind of on the L1 in the data collection and metrix collection side to basically get a data picture for how much kind of headro we have for such an increase and and here again basically the call to action uh we actually had um friend from the base team um come on uh on an alod devs I think that might have been two weeks ago if I'm not mistaken two is more or less two weeks ago um basically um give some data from from the Bas side that was very helpful I think for for kind of informing the decision and so if any other el2 also

basically has some strong kind of opinions on this um I think Public Communication is always always appreciated especially like also if you have some kind of ideas of like how your demand for blobs might change over the next say six to 12 months that that that will always be be help to inform the decision um and of course again if if the the presentation by Franc was was was very well kind of worked out um so if you basically are willing to to put in that level of effort um then you can you're also always very welcome to to join the ACD process directly um so yeah that those those are the two main points uh on the Petra side and then just basically for your planning um push to fusaka as I said already is pias but also the um EF ether

object format um changes um and of course on for there's a bit more wiggle room yet so like none of those are completely confirmed and there might be additional features and everything but but basically UF will not be part of the first half so if you have idea if you have plans to to basically have support for that on your chain as well and just know that that is on a slightly less aggressive timeline now than than say 7702 but that's kind of all um really the last few weeks of EP were very focused on kind of this two two part split and then the the kind of the progress towards Spectra so there wasn't much else um yeah and I hope hope that was that was helpful course happy I don't know if

there happens to be a question on on this specifically any of this specifically I'd be happy to take to answer that but so I see there is a question rounded um timeline oh yeah but but that's car already answered exactly so of course the the exact timeline for Petra is still unsure um I think basically the idea is always we try to to to have a have a for go live as soon as possible something like jary is definitely conceivable um I would imagine that like if it's say early next year um I don't think it's it's probably unrealistic to to to have the hard F on L1 go live by the end of this year so if it's early

next year I would assume it's probably not going to be Jing more February because we have these the test Nets that that we usually um f before um could of course also be a bit later there's always some room for delay if if testing doesn't go super smoothly or something so I wouldn't necessarily count on on safe February yet that's more like say I don't know my kind of optimistic realistic kind of um estimate but but um sometime you know first half of of of of next year and some for okay um thanks Anar and then I guess

back to you again about the Ral breakout that we scheduled for two weeks yeah sounds good um yeah so basically uh we we decided uh to um um give a presentation to basically kind of um update people in general on like our thinking around broal and also the broader kind of Ip process and the future of of um the evm um especially for like evm equivalent um l2s um and so basically that that's been kind of long time coming car Y and I we've we've been kind of um

collaborating on this topic for for a long time um and so basically in two weeks at the same kind of roll call slot it's going to be like a one one one hour breakout um we want to basically like um give a bit of an overview of our thinking um and so basically first of course just just describe kind of like what's what's what how do we see the concentration we have um a lot of um e equivalent l2s they all right now kind of um equivalent to each other but also equivalent to L1 and of course with with with individual extensions on top then um um talk a little bit about like the challenges and in particular of course there's just some things that L1 does not need that are would be helpful in the L2 context so that is they L2 spe L2

native pricing gas pricing things more advanced features like transaction paraliz more cryptographic Primitives native account obstruction um some solutions for State growth especially for El that have Ambitions to basically have higher blut numbers and and for that reason higher state growth um in general um all of these course challenges that um in principle can can be titled by l2s individually right so like we can basically just have the common base of the L1 equivalent evm and then just have l2s individually solve this U our kind of question that we've been thinking about for like the last year has been like is there something that we can do in a more collaborative way um basically using the fact that that um all these different l2s use the same kind of shed base um and so we want

to basically just present what we think might be directions that that could be helpful here um and we have some concrete um steps towards that that um that that that that we want to talk about there um but of course just just to be clear right this this is always kind of like fully oped in we're basically just um just giving our take and at the end of the day all Els will always choose their own paths um but we are pretty excited actually that we have we have um ideas here where we can basically have more evm side Innovations again especially um possibly especially in the in the in the L2 context so yeah it's I'm I'm personally very excited about that two weeks from now I think that's going to be a good breakout and um I'd be very happy to see as many of

you all as possible there um quick question um we had said that we would do the breakout for for the um L2 um transaction fee apis back in two weeks you look in the chat ah okay I see um yeah then we can I mean I can I can move it a week if you guys if you guys want but it's like it would also be helpful if the breakout sessions were like advertised because the last one that we had on the on the AL transaction status because it wasn't advertised um except in the in the telegram was was poorly attended that

was the problem see um yeah um I mean first of all of course yeah both my my apologies that that's uh that that scheduling conflict is on me um yeah it would actually it would be appreciated if we can find a way to maybe reschedule um your breakout called there by by week in either directions one week earlier or later um because because for I think for K and me unfortunately that that week really works works the best okay no I I can I'm I'm perfectly fine with that that's not a problem okay that that that's much appreciated do would we want to to pick a time now then just just so people on the call are aware um uh yeah why don't we do it do it do it exactly um wait a

second one week later one week later that that works that works well okay so then we we basically one week October October 30th sounds good yeah and um my apologies about like the um your kind of earlier breakout um kind of over this last cycle um yeah I was saying I kind of I was I was Bally relatively offline for the month so that's why I mentioned before that we might not be able to sport it as like a official kind of R Co breakout um but yeah um that one too right right um let's let's try for the other one let's try to basically make sure that that that people are aware um and can you remind people as

well like the upcoming one the one in in three weeks then what what will which of the two will that be like what what will be the topic uh there will be the the L2 transaction fee apis back sounds good and maybe maybe just give like a two sentence kind of summary again of like um who who that would be most relevant for uh that's going to be most relevant um uh for the clients that are that are that have the you know the status the the transaction status and their transaction receipt so it's it's just basically um aligning on on on the different different statuses and um um and the meaning and and and the numbering system um such that wallets um

and users have a consistent um experience as to as to the the at least the the uh the most common transaction status goal post so to speak that that all l2s will have in common um the pr um uh the spec allows for additional statuses um but the the suggested statuses um are in in the transaction spec um in the transaction status spec are for for um are for for given um uh are forgiven uh um for the most common set of transaction statuses and

sorry that was and for the API spec is just a it's just a get um get imp post requests as so um for the for the um so post what's the what's the um expected transaction fee um for transactions so an estimation um and then the the um the other one is a get which is once the transaction has been submitted what is the um what's the uh what are the different transaction fees are going to be so just breaks out the the overall transaction Fe into its um standardized

components which is priority fee data fee and and also execution fee okay sounds sounds good so um that that will be then three weeks from now so um yeah yeah let's let's make sure that everyone who basically um would would that that's relevant for um which of course is is all the l2s but like there might be individual people in the l2s and that on that side that they aware um yeah and then thank you for basically moving that so then we can have the the kind of the L2 evm breakout um as as just announced in two weeks and um yeah yes I'm I'd be yeah I'm very much looking forward to

that one as well cool great uh thanks on and um yeah I think that brings us to open discussion any other topics people would like to chat about going once going twice okay that's it then thanks everyone for attending and uh yeah I will see all of you at the uh the the breakout in two

weeks thanks all thank you thanks everyone bye cheers bye thank you by thanks bye