RollCall #2.2 Breakout: L2 Fee Markets

Transcript

yeah uh hello everyone um welcome to the second uh roll call breakout call to today the idea is to talk a little about um fee markets and specifically of course the on on the layer two side um account situation what what might um change in the future what should ideally change and and how how we could do that um I thought for structure it might be good um I prepared just yesterday evening like a little one minute two minute kind of brainstorming presentation just kind of my my thoughts the way I structure kind of how I think about it and maybe I I start with that and then we go into like a quick round and have the different teams that are on

the call kind of pres present oh not present of course just just briefly kind of mention how how they think about it if if that sounds good so I'll um briefly share my my screen if if I am able to do that let's see do anyone see my my screen yes awesome okay sure yeah again as I was saying like super super um quick um so basically uh the idea is uh the way I kind of thought it might be might might be

good to structure this would be to to kind of like have it SE BR into three topics so one of them is just taking the evm um with evm equivalence right that kind of uh the old topic comes with many kind of problems because the evm was originally designed for layer one the lay one context and so um just the simplest thing in terms of f Market just to to try and kind of do some repricing um yeah then then then the question was specifically is how uh in the2 text how to best charge for the the the the portion of the of the fee that that go to ler one settlement cost and that availability and then the the third one um that one was the last minute Edition um so I don't have much thoughts on that

but um but the question basically just being is the the kind of the model of congestion pricing that we use on1 that the resulted in e559 even the right way of approaching this in the l two context so basically does 1559 make sense um in the l two context so um on the on the gas cost aside basically the idea is um in general there might just be somewhat different um relative uh kind of cost or or kind of Maximum availability of of different computer resources on there to than on one say bandwidth versus compute versus storage access these kind of

things so so how to ideally kind of price that all more more appropriately and and then of course in some like especially on the ZK side there might be some specific operations that are just vastly more expensive and so ideally of course those also want to be repriced um challenges of course is that um if you make Bast um changes about pricing then then a lot of existing contracts that people would just want to Port over to to your network either just don't work at all anymore because they made some assumptions about pricing or at least they are now way way inefficient because they they no longer kind of they're not specifically compiled and optimized for for for that gu schedule um and uh of course you also also requires client

modifications is there some sort of way of making this very easy in in a modular way of of of of of doing these these modifications um and then of course again kind of if you need contracts to be specifically compiled with that in mind how do you have language and tooling support these kind of things um and just to mention kind of potential Solutions or things that might help with this would be um I mean of of course one the IP process for standardization if we if there was some specific kind of core here that that many teams would find useful then there would be maybe a way to to to make it more more feasible to to have that adopted um and then in specific uh and I know we have some uh people from ipsilon on the on the call as well so once we

get to this in the open discussion section um that that that'll be great um there's this this um proposed feature called EF so kind of version by code um that one of its goals is to remove uh kind of gas introspection from contracts and that way it would at least make contracts more able to run on on on instantiations of the evm that have somewhat different pricing under the hood um so that was kind of topic one um again I'm just going to go quickly through them just to kind of have have some something that we can then refer back to so the second topic kind of L1 um settlement uh fees um in a way basically kind of thinking

about it as like a very very basic version of a two dimensional fee Market um of specifically because the the the the level of a one fees that you charge users right that is completely independent of of the of the current congestion level of the of the L2 um and with the annoying exception of ZK robs that actually commit to State diffs um uh the the you can already predict the exact kind of settlement cost or these kind of proportional to other transactions a transaction by looking at it without even executing it which is nice um and and right now everyone I didn't want to inty by saying makesi mechanisms but right now every L2 kind

of has like their their own kind of way of of how to charge for that but it's it's not necessarily ideal and so um ideally you would want to have some sort of 2D uh solution there although one thing we could talk about maybe maybe this is just not an urgent thing maybe this is just fine as it is but but basically ideally to to solution um standardized across layer twos and then the big one that everyone always mentions okay um um yeah so so so the one people always mention in that context is kind of the the the how hard it would be to have wallets and what not support a new

transaction type um one proposed one idea here would be to I mean a with e 484 now we have a transaction type that has two dimensional pricing so we could Bally copy that and just repurpose that um uh blob pricing for for the L1 fees instead um and then again kind of the idea would be like with leveraging IP uh the nice thing is if if there was such a transaction Ty would be completely optional right so like as long as wallets want to keep using the old ones that's perfectly fine but then maybe over time um we could see slow ad option of of of that transaction type if if it makes sense to introduce that and then the last topic just to briefly mention it congestion pricing so basically just the idea being that on layer one we kind

of arrived at 1559 um after some years of iteration uh just because it's a pretty good fit for our model of of kind of um congestion pricing right where basically like we don't actually charge for for like like for transactions because to to reimburse I don't know users running full noes it's really purely to to kind of decide who gets into the limited box space we have on the two sides it's a bit more complicated of course you don't have quite fixed throughput because there's more kind of variable batch frequency um of course you still have some sort of congestion sequencer appr kind of uh choke points chain growth all these kind of things so it's it's also not like

it's congestion is not a factor at all um and possibly want to kind of charge above clearing right CLE price kind of um prices at least that that that could be an option and so question is does it maybe make sense to kind of try to unbundle 1559 and adapt it or like only pick some of the aspects for the l two context in particular kind of the way at least I I want to I think about it is kind of 1559 is kind of the the combination of these three things um kind of the base fee Oracle the the the the way of kind of making the the revenue go to the protocol and this kind of nice second price auction um aspect for for users so so is there may be some subset of that that that that we could

break do in the to context in a different way so I know that's those were just kind of my thoughts when I Was preparing for this call um yeah and then I guess the idea could be now um I'll I'll stop sharing for now and maybe we can we can we can refer back to these slides later the open open discussion but to maybe just go through the uh teams that are on the call and just have your all very briefly kind of mention is Fe markets a topic you have thought about to what extent have you thought about that in the past what kind of maybe beyond what I mentioned just now kind of our thoughts you have and just kind of to to get it started so um yeah if if

maybe someone from from from the teams here could could just raise their hand and then we go around well Ed if you want to start sure yeah hi everybody I'm Ed from offchain Labs uh we're uh the main developers of arbitrum um for us the top priority for standardization is to in standardize some way of expressing the pass through L1 cost settlement and and data availability um to have some transaction format and um API calls that um allow that to be expressed instead of having to force everything into a onedimensional model um we're not it's not clear I think whether the EIP 4844 format um is

quite a fit for that because it seems to be assuming that what you're paying for is data um per bite and um I think it's a little bit more complicated than that in pricing um one thing to consider I think is if we're going to be adding a dimension to gas um pricing and maybe two Dimensions one for blobs one for pass through data one for and then of course the original gas um I think we should consider um going the next step and creating a standard for multi dimensional gas generally um as far as the issues that um uh that ancar mentioned on the slides um I think several comments first of all for L1

fees the sort of pass through fees I I think there are two key issues there two key challenges in pricing one is that the price per unit is determined by someone else by the L1 or by the foreign da service and not decided by us so it's a different kind of problem it's more a cost accounting problem than it is a price setting problem um and second we can't in fact predict the exact settlement cost of a transaction um the exact um uh pass through um cost that it will impose for two reasons one is compression because transactions this transaction will be batched and compressed together with data that we haven't seen yet um and second because

of time delay that the transaction will be posted onto L1 for data availability but that won't happen until a bit later and so the relevant L1 price is not the current L1 price but whatever the L1 price is going to be when it gets posted which we don't exactly know so I think there are some different issues there um and so I think these sort of pass through costs are fundamentally a different Beast than uh than other forms of gas uh in terms of congestion pricing I think we see that the the problem on L2 as closer to the L1 problem uh perhaps than maybe some others do um the um and the mechanism that we currently use is pretty close to 1559 the main difference is there's a minimum base fee

that is designed to ensure that costs can be covered um but it's an active research problem and we're doing active research and maybe innovating in the future in this area how exactly to set um the primary gas fees in a way that um uh that better meets the sort of mutual goals of the chain but we think that that that the problem of congestion pricing for l2s is pretty closely aligned with the congestion pricing problem for l1s um as far as repricing of um instructions we put a lot of value on being compatible in terms of the number of gas units used by each uh operation with ethereum and so we would expect to continue to move together with ethereum

on that issue that's it thank you that was was very helpful um Peter you want to go next uh yes sure hey this is Peter from scroll just to reflect on nar's slides so in our case in scroll we do have this new dimensional fee for the settlement fees called the L1 data fee and uh yeah this is a quite similar to optimism from what I know I think arbitrium is a different mechanism so might be hard to standardize it but I I agree there's value in standardizing the mechanism here for tooling support and I also wanted to mention the issue of

compression but add already mentioned that that we cannot exactly predict what is the contribution of today cost of each transaction but I think even with compression some heuristics work fairly well here um apart from this I think a multi-dimensional fee Market could also be interesting to to be used for proving fees so that we can directly charge for the proving costs for each transaction so we're very excited in exploring that in the future great um thanks for that do we have any other teams on the call maybe if you on the call from a team but you're maybe

not the fee Market expert or something could be still be interesting if you want if you say hey we've maybe thought about this a lot or not not yet so much uh I don't know the details but you know something that if anyone he hello [Music] my name is caros I'm from polygon zbm team and okay basically uh first I want to explain a little bit what we do is we introduce kind of a new uh field in the transaction which is not excited is selected by the sequencer and it is called the effective as price and basically uh what we could do is to just reduce the gas price that we chge to the

user in order to chair to chge a fair gas price which includes the layer one that availability cost and um the layer two uh standard eum gas I would say then um I think that one challenge that we have ahead of us is how to price the zero knowledge resources that a transaction consumes uh we have defined kind of six uh GK resources in our case and I also I think for example the resources are the K Machine binary State machine arithmetic State machine steps

and so on and here one of the difficulties that I see is how to price how to standardize this uh ZK resources between different projects since we have different would say proving systems I mean it's not clear uh and not a easy path in order to do that that's basically my thoughts great thanks yeah it really seems that um there's some specific issues um in on the ZK side that that are especially kind of um interesting as well um do have any

other teams anyone else yeah hi my name is elas I work with the kakarat at KVM um yeah we've just started to think about the like fee markets um as you may know may not know we like kak at km relies on the like stocket OS so like the underlying stocket client and currently stocket uses like first in first out so no fear Market but we're AC looking into it um especially because we've chosen to kind of go the no repricing route kind of what I believe Ed said for

arbitrum which is a even though for us under the hood uh like kak is not priced the like the same way as L1 we still use the L1 price for lack of better solution for now so there is a disconnect in this there's also a disconnect in congestion so I think I think we're we're very interested in multi-dimensional gas um but yeah we're just just getting started in understanding the the ins and outs and the the challenges of pricing correctly um so for now everything is included one dimensionally in the gas price the L1 data availability the shared PR costs and the km steps that we

that like emulating the evm and cures so it's a bit it's a bit it's a bit rough but it works but yeah let's it thanks thank you um anyone else okay well looks like that might have been oh this is hi no this is um um Andreas FR from um um I'm co-chair of the um uh layer 2 ceriz working group uh

in the E EA Oasis Community projects and we've been working with like offchain labs and uh you know ZK s medis um optimism uh also Linea and a few others on a uh on a transaction fee specification not at the um technical sort of like interface level but at the at the at the level of actually how you define all the all the different terms and what are the requirements around uh um the fee structure so multiple fee components um and we are um and we we just uh uh published a

draft um and we're we're calling out sort of like the the the challenges especially around the um around the data fee for posting to um 121 so there're you know they're just simple requirements that you know towards the end user developers Etc that that um when you're displaying a fee um must be met so I think that's a that's a that's a first step but from a technical Tech point of view I think there's there's the opportunity to um think about um particular the data fee in particular because it varies so greatly across um al2 and in order to provide a sort of

like a more stable uh fee towards uh um towards end users is to do um uh to do option pricing So you you're basically pre- buying um and then um and then uh um follow that up with a hedging strategy um in order to to to um you know uh smooth out uh pricing so um thinking of thinking of uh treating treating gas uh just like any other commodity you would use um you know in terms of uh uh like oil or or or gas so but I can I can post the um I can

post the link to the yeah um I do remember kind of in the chat yeah seeing seeing that that the couple months ago that's a really good point I I did not know that you just published something um also I'm not sure if you are in the role called telegram chat but if you are would yes I am yes it would be great if you could also post the link uh over there as well for people who are not on the call and um and and and and and I definitely agree with lot what you said especially also like I think for example things like option um kind of um basically smoothing out uh the the the the cost to pay on for settlement um I think that's maybe

probably out of scope for this SC but it's definitely something that that um I could imagine emerging maybe like you know as a as a as a kind of extra service or layer in between that I think would be very valuable um and I even remember when we were preparing for shipping for it for for that there was briefly discussion do we want to have an option options Market embedded natively in the protocol um we decid against it for complexity reasons but anyway yeah um Alexander I see you also have your hand up do you want to go next yeah uh so yeah Alex L uh so just to uh briefly sum up how we we handle the fees uh concretely we we

just apply a multiple of what it would have costed on L1 uh and we apply this multiplier so on average it would be something like one over 15 I'm not sure about the exact number I don't uh I don't have the direct knowledge of that uh and depending on the variation of the cost on eum we may change uh we may change that multiplayer and so that gives us a very rough way to uh a very rough rate to price L1 data but at the same time it has the benefits of being from a user point of view exactly the same thing as if you sent it on eum which I believe has some value uh

but we believe this will uh be even more rough once we uh EIP 4844 comes out because then we will have to accumulate for the imprecision of uh uh as we send data but the cost of the BL since we will send it on blob and the cost of sending it in a blob will be variable versus other Cod uh and this will become a less acceptable solution so we are actively looking into what could be uh a valid multi-dimensional fee solution without uh compromising too much on the uh uh on the user experience for that

thanks uh oh yeah one more um but you want to go next I see that you're unmuted but I cannot hear you in case you're speaking can you hear me now yes go ahead okay hi I'm Bert with block native uh we provide gas estimation um so I've been working on improved pricing mechanism for blobs um based off of the you know the exponential formula and so uh long story

short it it considers recent deviations a lot more than the current algorithm and so I think this will be beneficial uh well it will be beneficial after like large spikes of usage then the equilibrium will return a lot faster maybe not an issue with blobs right away but with 1559 like the really large spikes it takes you know an hour for the price to to come down so uh it's basically a proportional uh integral controller like the current blob uh equilibrium is a is an integral controller on the the log space of of of gas prices so it adds basically a current error and just corrects things faster so the simulations look pretty

good I I'll go ahead and post it I'm still working on like analytical Solutions but I'll just post it on the Forum and see what everybody thinks sounds good thanks for that as well um and if you it sounds like I'm not sure if you already have something to share if if so you could also put it in the in the chat but if you're publishing something soon then yeah also ideally um if you then put the link in the roll call chat that would be helpful um okay do we have anyone else I guess now we had quite a few people um otherwise we can okay give it a few seconds good um and then we can move to

the kind of the the discussion uh section let's see of course might be a bit of a challenge with so many people but um um let's let's let's try uh yeah I was it sounded like from from from listening to all these summaries that probably the one pass through is the one where we we will have the most kind of to to talk about U maybe we still kind of stick to the order in the agenda um so that would mean that we we we first talk about just general um repricing it sounded like um a lot of people here a lot of teams were basically saying that they were pretty committed to um not deviating from L1 pricing at all um I think that seems

like a very pratic choice on the optimistic side on the ZK side of course that is very costly because um then now now you have to kind of artificially subsidize cat check and these kind of things um yeah I I don't know how to how to um kind of start the the conversation um maybe for ZK teams to what extent do you think it's it's going to be sustainable to basically stay on the L1 pricing schedule forever and just subsidize these things or versus to what extent do do you basically have feel some sort of pressure to try and move move to to world where it's easier to to repice things versus L1 evm oh yeah one

uh yeah so so far we uh adopted this uh approach because it allowed you to use the gas pricing mechanism of eum the question for Now does not uh matter too much uh because in the way linear work currently is we have a limit in the number of blocks that in the number of Kack blocks that we can process at once in a block uh if a transaction does more Kack than that then the transaction so then the transaction is simply uh not executed uh and so the limit is set in such a way that uh it will be uh practical for any uh purposes uh for any

purposes so in practice it does not limit too much the number of use cases uh but in the future we would like toh to improve on that uh but what we have that even with this limit that is in practice never really reached we do not have uh uh we are not paying the most because of KRA I don't know if what I said was clear but yeah that makes that makes sense and yeah and it sounded like say I'm not quite sure who there was there was some other ZK team um uh that that that said that maybe

kind of a multi proper multi-dimensional kind pricing model would be the the better solution than than just repricing in the existing Dimension so we can also touch on that once we get to the next topic of multidimensional uh St do I say that right yeah yeah thank you so yeah I'm I'm from ZK sing and yeah so in our case things like K they work fine but you know if we were like to try to have this the same up code pricing as on evm then there would be definitely some problematic up codes and yeah multidimensional pricing I would say is definitely the best longterm way to go but I was just like

as a random thought thinking that maybe and generally interested in the opinion of others about such approaches if we charge during transaction the same way as on evm like the internal schedule is the same an evm but at the end of the transaction like after the main execution is over post charging for you know whatever execution was too expensive so for instance if KCK was very expensive like compared to actual add op codes maybe and if the transaction use like thousand of cash checks then maybe at the end of the transaction we could charge thousand guas more in addition to whatever was

used in the main execution tion part this way inside the execution the behavior is fully VM equivalent that is all security and variance are preserved but at the end the user will still pay for whatever happened so ah no yeah sorry never mind um yeah never mind understand why it don't work okay yeah I think we can maybe have a talk about the multi-dimensional side of this uh once we get to the next section but Ed did you want to say something sure um yeah I just thought would be useful to unbundle a couple of different

things here one of them is do people charge the same number of gas units per evm operation as the evm and the second is um whether the the price of gas is is different right it might be that some team wants to make catch require a different number of gas units but still use onedimensional gas pricing um or alternatively they you know you could use two-dimensional gas pricing but I think the term pricing sometimes um actually is incorporating those two separate Notions you know gas units per operation versus gas price yeah thanks I think that's really

important to make that very clear when talking about this so basically yeah in this section I was I was specifically think about just charging a different amount of gas units for operations than L1 right and so basically rups that want to do this I mean right now I don't think anyone does that I think right now everyone Lally just copies the EVMS is that's the point of evm equivalence the question is is there is there a need to change that in the future to enable to change to to to be able to more easily do that and maybe in a standardized way or is alternative more alant solutions like multi dimensional pricing the way to go or maybe neither of the above um right uh I I see that Al axic is on the

call uh given that kind of the the ion team has been working a lot on euf and that UF kind of comes with with kind of this removal of gas introspection which I guess also then is important in the multi-dimensional context but uh maybe here ready uh ex could you maybe very quickly kind of talk that portion of UF and give a quick kind of UF um status update um sure so it's not only me on the the call from ipsilon but Andre is as well here um the maybe the quick status update is that um the EF uh specification is quite stable and has

been for uh quite a while most of the changes going on are kind of min school or um you know concentrate on one or two specific Parts um but the general design is is kind of stable uh there was one larger discussion we had regarding the general design but uh we decided against um making bigger changes there and we do have a e implementor call which has been Bi weekly but starting this week it's weekly um and we moved the uh the time of it to not be conflicting with the roll call so um basically it starts after this call um and anybody is U more

than welcome to also participate there uh to learn more about the UF on a on a weekly basis um the specific uh solution we can offer to this problem um well yeah maybe because um Anar said to give like a short intro so EF is a larger set of changes uh to the evf M uh which introduces a number of different features which evm currently is lacking um it introduces versioning introduces structure where code and data is separated uh it introduces um sub routines and a lot of uh basically transforms all the jumps to be static instead of

dynamic um and also introduces a number of different changes to reduce introspection capabilities uh the two introspection capabilities I want to highlight here is uh one is code uh introspection uh in the EF Paradigm it is not possible to inspect the code uh of any contract in platform uh which means that um in theory code becomes upgradable um because you could replace you could transform and replace account code um because the the code is not able to introspect itself or other contracts um in theor this as possible the more

important piece however is what Anar mentioned is the gas introspection and the way we uh limit that is we do change all the coal instructions uh to not take a gas argument and we also remove the the gas instruction and anything related to it the actual gas rules remain um the same uh because we really wanted to to make this more like a step-by-step approach uh and so we do do still have the 63 of 64 trule um but with not having this inspectable that could also be removed in the future um so with not having the gas argument in any of the call

instructions and not being able to uh inspect the remaining gas um and passing uh all the the gas uh for forward uh this means that the only place to limit gas usage is at the transaction level um and we think that this would solve you know most of repricing problems because you could you could just change any of the pricing and the single point where uh you have to make an adjustment is at the transaction uh execution level when the user sets to the complete transaction limit um I hope you know because I didn't set any slides here I hope this on a high level made made some kind of a

sense um but lastly we're also launching a UF website which would explain this in much more detail uh which can be there's still updates needed but it will be at evm object format. org um and we have a combined specification explaining all these different parts of EF um but we do have IND individual eips um for the individual features um so that's like in a high level intro awesome thanks so much Alex and uh yeah just just just to um to give a little bit of context so basically um

this this this change has been proposed on mayet for a while it's still unfortunately not 100% certain if and when it will um reach mayet um in this context specifically of course it would be only would be relevant if it also um or alternatively comes to is shipped on the on the L2 side so if and we can talk about it some more on the multi-dimensional pricing side if that if if it turns out that that would be really useful it could even be that this could be a candidate to ship this via the IP process nice thing is that most L1 clients have already implemented support for it or at least are close to it so so it could be something that actually could be easy to maintain even as a L2 feature um uh L2 only feature

something um and of course the reason why it's relevant also say for multi-dimensional pricing is that it now allows us to change how we count for gas on an ongoing basis so that instead of one gas counter there could be multiple gas counters and everything which just isn't really possible in the current evm because you only have this one gas up code that that expects a onedimensional answer when it asks for the count count gas um is there on the on the repressing set itself I I assume we'll get back to this in a few minutes uh on the multi-dimension side but but on the on the repricing side itself is there like something else that that people would want to touch on okay then um I would say we we move

on to this the kind of the the multi-dimensional side so so I I guess I didn't really mention the kind of General multi question of multidimensional pricing in in in in my in my notes so maybe we can we can have have like a two sections first we we talk specifically about the um the L1 settlement data um um charging um and and then we talk about the more General multi-dimensional um pricing also say for for proving and these kind of things and the reason why I didn't kind of call it multi-dimensional also was I think Ed mentioned that as well is that like kind of the the L1 settlement is is is UN special in that it is externally kind of determined price that you don't set

yourself so in a way it doesn't seem to be quite quite a proper two-dimensional um problem it's more of like a special case of just external costs for transactions um and also sounded like my assumptions were a little too simplistic around um the the the feed they being prct predictable from the outside of a transaction because of both compression and then of course the non dat C portion of of settlement cost so point taken on um yeah I don't know how do we get best get started on the conversation here um it seemed like there is definitely more of a demand on this on this topic for for for

standardization um yeah I mean I don't know maybe I'll just open it up for for General discussion and okay I'll go first um the I think there is probably stronger agreement on the need for transaction format support and API support for communicating with users and applications about uh the L1 fees um or L1 costs um there's more I think there's more probably alignment around that than there is alignment about the particular way that these fees

would be calculated or passed through um and I think that there's less alignment about the second thing for two reasons one is different kinds of systems have different balances of costs right so ZK systems have higher proving cost for example um but also because there are differences in design approach among different rollups about how they handle this so as an example for arbitrum it's very important to us that the chain almost never reorgs um and we also make it a goal that the pass through pricing mechanism be fully trustless um some others have different goals um maybe they worry less about um about reorgs um

because they you know because they're trying to prioritize something else for example so I think if we can standardize on formats and apis I think we can make progress more quickly than if we try to standardize everything yes it's a very good point I think getting the standardization boundary right of like what to send us and what not is is very important so it sounds like basically what you're saying is um the just the how to charge for it that's the the part you you'd want to basically like the just the the mechanics of of kind of of of how to expose it to the user that's what You' want to standardize and then how you actually come with the with with a fee that's what you basically would leave up

to each L2 yeah exactly okay and um I mean of course question there is whether people generally feel similarly about this and then also of course I think a specifically a good question is do people agree that having a specific just transaction type for this because standardizing on a transaction type would be the the main area Focus for for standardization um here I I think you would also want to standardize on apis for things like gas estimation Ah that's a very good point yes transaction type and apis Carlos yeah I think that that think a

new transaction type um and I'm guessing here it's just a question um it's about just starting a new field like layer layer to uh gas or something like T later to Max gas allow it to church to the user somehow and later on each project could have kind of a table with its own gas consumptions in Layer Two so it's a standard for all the layer twos but later on each layer two will Char whatever they want so basically this could be an approach that we could follow and I totally agree about uh doing ANS modifying estimate G or whatever in

order to add more data or in order to rec more data from the RPC VI that's for the wall basically I'm not I'm not so sure about the upside of having a new transaction type because it's nice to displace to the user that like um the breakdown of where the gas cost like the gas price comes from like whether it's pass through whether it's I don't know premium whether it's proving costs and so on but then at the end of the day they're going to be like all summed in the like overall gas price and this is

still what is going to be sent to the like L2 operator I mean there is an upside I guess but there if if if the if the main goal is to give more data to the user why not just modify estimate gas so that they can they can know the whole breakdown of their of their operation rather than I don't know what what yeah yeah I have some thought on this but let's first hear from the people with the hands raised Peter yeah I feel like we might not be on the same page on like what we are charging the user is it e directly or is it in gas units like in our case for data Fe we directly deduct that from the

balance so in that case we might be okay without the new transaction format or maybe with a new transaction type that just comes with like a maximum data fee uh but for us specifically the API standardization would be more important so estimate data fee that's one API and the other one is to add the data fee to the transaction receipt but I feel like there are some R projects who not who do not charge in e but in some gas units so that might be different yeah that's right um Andreas yes um

so I if you actually look at the at the at the spec that was published so we're we're breaking things out into at least three components for now um and there is there's an there's the L2 fee so that can have different components based on the L2 so there there is um the opportunity to break things out further because you know you have um if you think about you know further decentralizing like a ZK um evm or anyone in sequence or improver then you have like two entities that are that are that are really have costs right the sequin are and the and the um and the

prover so um if you have multiple sequencers potentially also multiple provs then there's a there's a there's really a fee competition and it's more the the the key question is what are you um what are you charging the um the transaction sender in the end a that it's transparent and known ahead of time like when you fill up a car at a gas station right you're not driving up to the gas station and going like hm what am I going to pay right now no you look at it and you see a price you know exactly how much you're you're paying for the unit of gas right um uh and then it's up to

the provider to ensure that that price meets their Cost needs right so that's that's where where this um you know where a market is really important even even the market with within an L2 if the L2 is um decentralized right um You you can have multiple markets you can have Market within the L2 and then you have uh and then you have an have an uh a market for the um for the data fee right um for you know for the pricing for that so um and uh I think that is um uh you don't need a new transaction type you just need to have an effective

mechanism that allows to um to produce a known price to the end users um for a given time period right and then display what are the what are the uh what are the drivers or you know um where does that come from is it is it a is it an oracle is it a fee Market is it you know the sequencer you know sticking a thumb in the air and seeing you know which way the wind blows right I think I think it's fundamental in this space that the cost

of providing L2 execution versus the cost of L1 pass through Services those two costs fluctuate independently right we don't control how much uh the one is charging us for our chains or users for those services and so I think we do need the ability to adjust something about transaction cost to account for the fact that there is a two-dimensional cost structure um and the closest analogy to the way that the model that users are accustomed to on L1 is you use gas estimation to tell you roughly what it will cost but gas estimation also tells you uh also gives

you a hint of how much spending you should authorize right if you want to because the other important part of it is the user signs the transaction actually authorizing the fee being taken from them and so if you want to scheme where users where you don't take fees from users unless they've authorized it and where the cost of pass through Services can vary from transaction to transaction then you have what's fundamentally a two-dimension gas market and I think having two-dimensional um gas estimation and two-dimensional authorization from the user in the alternative is to really change the semantics so that for example

different transactions that are in the same block L2 different gas prices and that I think causes other form for example that it um destroys the notion that there is a current gas price right and to just very briefly by the way um give some context here so right now basically I'm aware of three different ways how l2s charge for L1 settlement cost so that is the the arbitr model of um and it maybe correct me if this is wrong but I think basically just um um adding it to the to the um General gas gas consumption with like a dynamic kind of ratio that that

that that you set at the time of EX ution and just charging it against the same gas limit is that right yes okay and then there's the optimism model or and all the op chains and I think some other people also use that for example Peter you mentioned I think that that you do that as well on scroll um where basically you just don't expose that to the user at all you independently just um take that out of the out of the balance um and then there is the third model that I know linear uses and I it might I might be if I didn't misunderstand that polygon the KVM also does that where basically you um just uh basic you don't have an explicit

separate pricing you just basically charge a little extra and um set that so that you that it roughly kind of accounts for what you you you expect to pay on on L1 um and so the the the reason why there might be an interest in actually standardizing this in the form of an explicit SE like extra Dimension and a transaction type and not just a way of making that like standardizing the estimation is to make sure that that this is um both under the user control so of course the tradeoff right now is that say on the on the optimism side the user just has no way of limiting of of expressing any intent about this so you have no way of of limiting the cost on this side I've I've done this in the past where I sent a transaction on on

optimism and I was like oh nice the interface tells me at most 4 cents and then it charged me 20 cents because of the settlement cost and that's of course not ideal um so basically giving that having that be both on the user control while and of course in arbit it is under user control but in arbitrum it has this other kind of trade of of now messing with this um existing mechanism of the of the gas element and you kind of in order to to have both of these at the same time you need um a separate um Dimension so that's that's kind of just the context for why why there might be demand for not just having the the estimation mechanism standardized but actually um do a new thing

here um uh yeah I would want to move on a little bit and just if you have um a comment on that narrow point do you want to yeah I I I I think the the the very notion of price variability from transaction to or of not knowing a price before you buy is is I think that very fact even though that's what it has been um I think it's just um it's just not going to fly people want to know what what they're going to what it what it's going to cost them right it's and that's only fair and by the way from a regulatory point of

view right even though some people might not really be interested in that here but um you know for for for us in the US for example with action that that that Congress is is currently considering um fees must be known and published ahead of time and you need to commit to that you can say oh it's going to be a fee but a fee is known so saying ah you know what sorry we can't do that it's just not going to fly it's just not going to it it's just not going to work so I think we need to fun fundamentally rethink um the whole notion of of of pricing and

really treat it as a commodity and then there are known mechanisms for how to deal with that that we don't have to reinvent the wheel for that you can actually go to to the Chicago mertile Exchange and probably uh um you know it's like ask them to to to to you know put out options and just buy it right it's a cost right right I would say just um because I do agree with with with what you're saying basically I I I think it's because just we have so many people on the call I think it's it's important that we kind of try to separate the different layers of the conversation and I think right now we're mostly talking more like the mechanics

of of of how to do that but then I agree once we kind of when we talk more on the say what then ends up kind of what what is the user experience right and then then I think what you're saying very much like I would I would subscribe to that so basically um yeah yeah the kind of the predictability and everything um on the kind of the the more pricing mechanics um I I would be curious if we kind of continue on that path of a exploring a like a transaction type and figuring out how to um how how to best make that work um what do people generally think that I understand not everyone think that

there's necessarily need for it but people generally think this is a reasonable approach of going about it the nice thing of course is that it's forward compatible like if a wallet doesn't immediately adopted even though I do think that people are maybe a little kind of have a bit PTSD from um everyone on the SC probably experienced that of trying to have a new feature and then because it's just one layer to shipping the feature a lot of tooling wet it's not interested in supporting it I think hopefully this will change a lot with these kind of Common Core of standardized IP features where um as a wallet I now have a lot of interest in supporting this as soon as possible but but even if not right the nice thing with the transaction type is you can always send the old transaction type if and we've seen that with 1559 as

well on Main net that um that's fine and so so so so it's it's it's an opin kind of transition um is there anything specific any specific concerns that people would have with with the new transaction type or challenges of um of of that role out um and then as a second question also Ed I think initially you mentioned that you think that say the 44 Pro of basically because it's just treating treating dat like it would to for transaction type repurposing that might not be an ideal fit because it just could only account for data maybe if you could also elaborate on that a little bit say a little bit about that right so it's kind of implicit in the way that 4844 transactions are expressed and priced that you're paying for all of

the data in the blob the data it comes in units of blobs and you're paying for the whole blob because the size of the blob is not in the first of all the blob data is not in the transaction but also the size of the blob is not in the transaction so I think you would need to whereas of course we want to be able to charge for um different sizes of uh of of data different data footprints for different transactions um so to me that's the main issue the for for the 484 front uh transaction type is just fundamentally has a has a built-in assumption um that you're always posting full blob and that the cost does not depend

on the contents of The Blob and I know arbitrum and some other and someone else mentioned it as well that you you uh uses fistic to estimate the compressibility of a transaction even in advance of knowing how it will be compressed ultimately right so what I'm hearing you say basically is that and this comes back to the question of what to standardize right so basically we need a way of just mapping taking a transaction and mapping it to a one-dimensional value of amount of L1 space that it will have to take up say that could be the data itself the compressed data but also maybe take into account the the execution that portion that's necessary for that and then the question is is

even does it make sense to even map that into one a onedimensional value you could almost imagine okay but I want to separately account for the portion of the execution for settlement versus the data and everything but of course then if if at least to the extent that we want to expose that in a transaction type it seems very very valuable to map that to one value so then question is is that mapping something we would want to standardize or just leave leave up to each L2 the intuition would be to leave it up to each L2 but then of course if we don't standardize it it's harder to then standardize the rest say the the the the the estimation if what it even means to have say one settlement gas if if the meaning of a settlement gas is up to each L2 there should at least be some

sort of rough standardization where say roughly say each standard each settlement gas would be you know one by of one data something something like that right um because if we don't standardize that at all that then kind of that field now becomes own way almost meaningless at least across across different l2s um so so what exactly to standardize in this mapping to one dimension question mark um and then once we have that I guess the rest is relatively straightforward right because then you just take the limit and the max price that the user set for that Dimension you multiply and then you charge or is there say is there are there other complexities in that it it seems like if you want to follow the model of the uh L1 gas

pricing that you would want to have a notion of what is the current price of settlement gas and then but but then the amount of the number of units of settlement gas consumed by a transaction would vary depending on the transaction itself um and and maybe that is how many catch acts it does maybe that is something about how large it is or how large it's estimate heris estimated to be after compression or something like that it seems like you could different rollups could have different policies for saying how many settlement gas each transaction took but the notion that there is a current settlement gas price seems

like it seems Seems to align with how people think about 01 right and then we would not need some sort of 1559 mechanism because that's an external um price right so basically yeah yeah that's right do you think in terms of standardization on the how do you actually driive the count price uh this seems also something that's probably not that doesn't make sense to standardize is say like basically some some sort of small portion of that to standardized some some some standardized way of predicting it or some standardized way of accessing that information because again I assume different letter have different strategies of um at the point of inclusion determining what actual level

to charge at I guess what I would propose here is to have a standard gas estimation API each L2 could have its own policy for deciding how many uh settlement uh gas to charge to each to a particular transaction but then you have a gas estimation API that someone can call to get you know the estimate of how many of those gas it's going to it's going to require right and then you could also have a um the the transaction format be like L1 gas where the user can say what is the max uh settlement gas price I'm

willing to accept and what is the maximum number of settlement gas units I'm willing to be charged for again aligned pretty much aligned with the model of of of regular L1 gas right and that makes sense and I would say by the way that that is mostly what I had in mind in terms of repurposing the for for transaction type just meaning that that also comes with these two extra Fields they they have different meaning semantic meaning of course in the in the block case and you're right that basically we can't too closely match that semantic meaning but I think Bic just having your transaction type that just has two extra fields for a a separate Dimension that's something um that we could B more copy or there's precedent for at least yeah and then of

course next question is should there be more than two right do you want do you want a format that allows more than two types of gas right ba based on this 01 Infinity principle right that maybe it makes sense to allow more types if we're going to if we're going to take this Step at all yeah and let's let's maybe first wrap up the kind of the L1 pass through specific kind of conversation and then and unfortunately already is only 20 minutes left on the car but that we can then um talk about I think that the main remaining topic is the kind of the dimensions beyond that um Andre you have your hand up yeah I think it would be the um about the gas estimator so it's it the um you

know if we specify the API what is returned could be sort of like a commitment to that price so you can have different providers of the gas estimator that will commit to the price that the user is not going to is going to be charged exactly that price yeah that's and actually by the way just to mention that because I think when we talk about this it's always kind of important to kind of separate the the responsibilities and now almost in my mind this is something where this could be in service that l2s offer or third parties offer on top of l2s basically just like committing like giving giving fixed commitments to to fut fut prices

um which I think I totally agree with you that it's super important for ux but I think it's not yet necessarily clear which layer of the state that responsibility would lay with well if you're if you're if you're doing if you're operating a pay Master for meta transaction or even just for for for um account obstruction the cost there it's like you know who who are you promising that to then then you you introd you introduce again you know variability that is is um that is problematic in terms of promising um uh inclusion you you should have a price where like uh a transaction

is is I the guarantee to be included or you know to to to know that it's it's it's not going to happen right I think that's really that's really uh that's really important also for for you know it's like just providers for meta transactions right or or um you know the the account abstraction that's not native right and to to because in interest of time just to kind of wrap this topic up so you can move to the general multidimensional um that was mostly kind of me talking with Ed here is there any other team that that has um kind of followup thoughts on on the

specific uh L1 passed through and the viability of of doing that with the with the new transsection type and I see that we have the typical fate of a 90-minute call that after 60 Minutes many people have to jump off or had had to jump off already um okay sure I actually think I personally would be really interested in kind of following up on this and maybe even kind of at if if if some if we could kind of have some sort of Asing kind of working group follow up or maybe just a collaboration with Abit

with a few teams that are specifically interested in this to kind of try and see if we can get that to an IP um reasonably soon because to me honestly this that seems like like a big win that's not that that hard to to get to um with of course the devil in details on what exactly to standardize but but yeah um okay then I do think kind of in the time left and maybe we can briefly also talk about this kind of congestion pricing question but I think mostly the big remaining question is about General kind of multi-dimensional pricing and again the reason why I didn't even kind of bundle that with with L1 pass through in the first place is that L1 pass through is almost like not not not not not even a proper second dimension even though kind of in terms of how exposed to the

user it would look like that um so the question kind of being a in general like what there's of course just a few inherent extra Dimensions to the evm that we we would have like if we were to restart the the blockchain from scratch of course we would try to just have inherent you know we have we would have compute gas and we would have kind of state access gas and we would have bandwidth gas and all these kind of questions so to what extent l2s would just really really want to to do that kind of thing versus just L2 specific types of extra Dimensions like on the ZK side the the the proving Dimension um and then kind of yes so so I don't know like I would just be curious with l2s that that have specific thoughts on on

on extra dimensions for the future unless we lost most of the people that that raised those points in early on the call uh I think this is something that we would be interested in exploring um and really for the same reasons that multi-dimensional gas could be valuable to L1 that you know there are good theoretical arguments that with multi-dimensional gas you can uh at least in some important cases get more

throughput um or have lower costs with the same throughput so it may be more efficient for users um and and it may also be that l2s run up against those limits sooner than L1 because we have more throughput and are and are trying to push the throughput envelope more so than L1 is so um it seems like a good topic to uh to discuss from at least from where we sit that may Mak sense and I think unfortunately we lost most of the people from the ZK side already but of course

there there's also the specific kind of extra um circumstance of the of the Prov um in general like the way I've been thinking about is basically distinguishing static versus Dynamic Dimensions so static Dimensions being ones that you can basically completely predict the consumption from the outside of a transaction because those are just um they're not conceptually different but they're just in terms of implementation they're much easier to add um Dynamic Dimensions where you basically have to now have a second gas counter running or a third or a fourth or something while you do the execution that's harder to do and um in terms of kind backwards compatibility that's now where we can basically look back to UF that we talked about earlier where basically it is relatively hard to do

that using the existing kind of evm with existing introspection capabilities because you have access to that that gas counter which inherently is a one-dimensional value um so something like that might require well might might be dependent on on on on a change like UF that would first remove that introspection um yeah I mean I guess one question could be unless I mean okay first question do we still have anyone on the ZK site on here that might have specific thoughts on the Prov dimension

it's a bit of an open end a question but uh okay um because because then I think just pratically speaking it seems if if we want to kind of move forward with with with something it seems I think at you briefly asked the question should should a transaction type that that uh introduces an extra L1 pass through Dimension should that kind of try to already be forward compatible with multiple Dimensions um it seems I yeah I don't know I would just be curious whether people have thoughts on that it seems maybe that that adds a lot of extra complexity for something that probably only is relevant in the medium to long term to me that's the main question is

how much extra complexity do you add by making it extensible um you know if we think that it's something we're going to want to do eventually and it doesn't add much complexity now then it's worth doing but you might need to do the exercise of actually trying to specify it to know how much how much pain it brings in the in the immediate term yeah and it's a good point that it's probably worth at least doing that um I would also say that of course with with all any of these standardizations across multiple alos it's important that semantically then it everything is identical and so the ice thing with the one pass through Dimension is that it's

easy to scope that in a way where semantically at least to the extent that the fields that are in the transaction have have identical meaning meaning it's kind of this this extra kind of L1 uh Dimension and and and kind of gas of sorts and then then then then it's up to LT to fill that with with more specific meaning um it would with with extra dimensions then the questions becomes how how do you kind of keep that as well um it would basically require the entire multi-dimensional surprising to then be a a standardized um project which might not be a bad thing but yeah but you would at least need a a standardized way to Express multi-dimensional pricing even if you can imagine for example that you have

like gas types which are which are numbered and zero is execution gas and one is settlement gas and then there's a range reserved for sort of uh L1 and then there's a range that l2s can use for for their own experimental purposes something like that well I mean if you're if you're if you're uh if you're introducing a new transaction type you might as well go all in and then simply replace you know uh a number by an object right if you're if you're expressing that through through Json object for example the the um uh the fee of the price then you can you can you then every L2 can can then

list the price components and and and um variability and what have you not um based on their own needs and it's still there's an there's an aggregate Top Value um uh and then you have the components listed and you just need to publish the schema and you're good right and that's probably something that we would want to get to the question I mean they specific problematic limitations in terms of how how just um actions are structured today and I think we kind of we are we can't go too too wild and so so so so presumably we're kind of stuck with the very simple simple way of doing it but

um yeah I think I think B basically what2 could go wild the l2s could go wild because you can you can do an abstraction right because because they have the freedom they can abstract out the the underlying sort of like L1 compatible uh um transaction structure and they can they can wrap that into into more into more Dynam or more more more flexible L2 structure that is then you know where you separate out sort of like what's what's required um with regard to to to the execution versus the versus the the the fees and the um and the and the pricing so if you're if

you're if you're thinking it in in in terms of different abstraction layers and you have different you have a wrapper I then then if we standardize that wrapper then uh you know then the l2s have the flexibility to to to express um their you know implementation specific needs um much more flexibly without impacting without having you know to tightly couple that to the to the to the um execution to the to the transaction execution structure that's that's required which is much more closely tied to the um to the L1 right and and to to two another

points on this uh one is just that um just uh pratically speaking I think in the past we've talked a lot about how L2 are very hesitant to move to too too much away from how L1 works just because that means that now you have to just maintain spec kind of uh deviating client uh behavior and so say different ways of passing a transaction object would I think for now be probably out of scope of what l2s would be comfortable with doing so we kind of have to pretty narrowly follow how how l1's kind of today um handle transaction objects and then also unfortunately of course um because the the majority of the cost for L1 settlement comes specifically from just the data size of the transaction

object keeping that as thin as possible and efficient as possible really super high priority so I think there's there there's a trade-off basically between kind of cost just like settlement cost and and expressivity of the of the transaction object but but I mean yeah I think kind of coming out of this call uh the my main takeaway is that probably that's the one actionable item here right that we kind of we we should just have some sort of very specific kind of follow on effort to just work on a on an iip for for for 2D or or potentially multi-dimensional uh Al transaction type that which I don't know that's that's very encouraging to me and I'll I'll kind of try and um make that happen

afterwards um yeah I'm I'm more than happy to like spent the last five minutes talking about kind of this question of is 1559 the right model for for TOS of course that's a big topic for a short amount of time maybe just to briefly we can briefly just touch on it just to to kind of get the temperature check just before that is there any any remaining um comments or or or points on this this this general question of uh L2 multi-dimensional pricing of course the general multi-dimensional I think that's a that's going to be a big topic yeah yeah I never know how long to wait

with these questions but okay um ah okay see I st yeah I just wanted to say like one small thing I'm not sure if it has been already mentioned on this SC or not but in the rip about account obstruction native account obstruction transactions there is already a field for Builder fee and if I recall correctly in the RP there they would said that potentially this field could be used to for instance fers to provide how much is are they willing to pay for the pub data or whatever else so probably whatever efforts are done with regard to multi-dimensional fees they should be made compatible with this r be

ored there H yes that's actually really good point I thought about this briefly earlier in the call but yes that that that that actually given that there's the general intent to move in the medium term to a 4 337 style uh account obstruction um transaction um model of course any of these changes would be quite Shar sided if they don't make like don't take into account that long-term transition and how how that all fits together I haven't really thought about it enough to to have a specific opinion on this other than this is important to take into account yes very good

point okay then um and if you know people have to leave then course please feel free to but um for for those remaining for the last 5 minutes um yeah I would be curious to to just briefly talk about General kind of 1559 um this's of course something I it only came to mind yesterday evening so I haven't really thought about that much I just be curious of course I assume that's a topic lus have thought about a lot given that you have to make these practical decisions yes so so I just be curious to to hear a bit more how Le think about 1559 versus other types like congestion pricing non- congestion pricing um unbundling potentially these these different

aspects of 59 okay so from from an Arbitron point of view we use something that is similar to but not the same as 1559 basically a version of the exponential mechanism to do congestion pricing um with a minimum price so um you know in a multi-dimensional setting if we're thinking about resources in a multip and limits in a multi-dimensional way there may be other approaches that um and

we're continuing to do research I think we may evolve how pricing works but the basic Spirit of 1559 which is tracking you use versus Target and then adjusting prices to try to reach equilibrium by an exponential like mechanism um seems in principle to be to be a good approach but we but we don't currently and probably won't do exactly 1559 right are there any other um as I mean okay now the calls really has Shunk

so I I assume we might not have anyone else left on the call that that has opinions on on on 1559 oh like 1559 like mechanisms F right then it's probably not worth at this point to to go going into it more because Al running up on time um then yeah always always a good fun topic for a separate call at some point but um yeah then probably good point ending

point here thanks everyone for for coming on especially of course those of you that made it all the way to the end um and I think that was a productive conversation and especially if you maybe can can follow up on on that that um idea of of a one pass R transaction type then we actually got somewhere and um yes that's all from my side thank you all and have a nice rest of your day and and just to mention by the way thank you just briefly mention it's still wrong on the calendar I'm I'm I'm trying my hardest to fix this on the protocol calendar but the next draw call will be in two weeks not in one week then in next week we'll have one more breakout call on the general kind of concept of standardizing pre-compiled

across lat and then the week after there will be another main roll call so keep that in mind awesome bye for now byebye