RollCall #4

Transcript

hello and welcome everyone to roll call number four that's issue 1013 in the ethereum PMS repo I'll drop a link in the chat um yeah let's get started so as I'm sure you know uh we uh we skipped the last call that was scheduled for just after the go live of EIP 4844 uh it seems like that went very successfully both from an L1 perspective and then from any of you here deploying blobs uh on the uh on the L2 side of

things um I was going through the base fee recently it's also the blob Bas Fe that is has been interesting to see um it's uh seems like we're still just hanging under the uh threshold or the target of three so blood Bas Fe is nice and low particularly now that the descriptions have died down uh which is which is really cool to see um and excited that this seems to be bringing down the uh the costs for many people here the other exciting thing that's uh sort of happened since our last R call um is we've seen RP 7212 R1 pre-compile go live on several

chains um congrats to everyone who's deployed this this is really awesome um and yeah I'm excited to see the direction this goes um but I think it's a big unlock from a ux perspective as you're all aware I think EIP well rip 722 is also scheduled for Petra yeah wait is it uh I've seen it in the mega Fred okay I didn't realize the scheduled I mean that's yeah it's just being considered I mean would be cool

and uh it's definitely something we can push on all one side and see if there's there's interest to have it deployed on the all one side as well so I guess from uh rollup um perspective everyone that wants to add sgx and I think there are several uh at least Tao does uh I've seen scroll mentioned it as well uh this would help uh on gas costs uh like reducing uh just sjx uh verification from uh a million to 100,000 or something okay that'd be pretty cool

yeah that definitely goes from the round of the realm of barely feasible to definitely doable um within a block okay any other things people want to mention on 7212 right um moving on the next topic is the BLS pre compile on layer one that I'm sure you guys everyone here seen lots of

discussion on in uh um in our chats uh Alex was going to pitch it but I believe he's unable to make it um the idea here and the the reason this is important to discuss in in this forum is um for the the chains that are targeting evm equivalents um particularly on the ZK side it could be quite complicated to um have to support um the the BLS pre-compile EIP 2537 um and so this is something that uh will happen on on L1 main net so the question is

just like is there something that the um the the the zk2 feel like they they can implement or would it uh is is something that we need to figure out a standard for having to to to work around not supporting on the AL two side of things uh is this just something we can solve with gas being different on L2 does anyone have any thoughts on this um well Tao is not live uh so we have less constraint but we are um uh adding support to the BS 12 381

pre-compile um I mean once you support uh BN 254 uh modifying to support BLS uh 12 381 is not that hard at least for uh addition and scalar multiplication uh hashing to curve is uh a bit different and the reason attaching to curve is is is L one what uh so there are two reason uh one is that there is no uh hashing to curve for b254 so we need to write a code from scratch um and the other one is was even

if it was uh it uses um BLS 12381 uses s Wu algorithm while b254 uses svdw okay all right um and then the other thing that I I think many seen discussed and what has been discussed in the um in the chats was in relation to uh whether we should do the subgroup checks and which function should have subgroup checks um the I mean that's a larger discussion and and and I think will be solved

largely at the L1 side of things but is there anything that uh like does does this have any effect on those trying to implement it um in ZK crypto um so the way subgroup checks are done is through a scalar multiplication but a very short one so once we you support SC multiplication in ZK uh subgroup checks are kind of free okay so you're not worried this there there have no concerns about uh the additional costs of it's it's it's less about whether it's feasible it's more about just the

marginal cost of how frequently it gets done yeah and that's not not too bad then on the gas cost uh I guess there is a tension between um like if you want uh people to verify um ZK uh on chain for cheap we need the gas cost to be very low but um at the same time for Layer Two if people want to use uh ZK Bridges uh maybe layer freeze and everything we need uh to be able to do those um like it should be able to reflect Pro cost on uh Layer Two but uh this is only an issue for um

type one uh um rollups uh and the only one that's type one uh at the moment um like there is none uh Tao will launch at type one we'll add some um uh pre compiles uh to well uh CIS calls accelerators SC processors whatever people uh name it uh to make sure it works but um yeah it's um there is a tension there for sure and uh this is also why I raised the EIP 7667 from vitalic uh which was about

raising the gas cost of hash functions by 10 x uh to reflect a bit uh the cost um in uh in ZK evm in type one zkm of proving hash functions um but the difference for elliptic curves operations is that um if you use uh like Aztec Goblin plunk or cycle fold you can actually reduce the cost of um uh elliptic curve uh uh operation proving while you cannot do this with hash functions you like there is a lot of research um with uh look up Singularity beus and things like this um

but nothing uh in production yet okay um I think that's that's helpful um anyone have any other things that like to raay on the BLS pre-compile particularly on with relevance to L2 nope okay great moving on um so the next one is EIP

7623 um which is uh aiming at increasing call data costs and uh I believe Tony wants to speak about that to Tony yes thanks a lot K hi everyone let me quickly drop some links here in the chat yes so in the chat you can see the the link to the EAP itself then the latest analyzes and also you find this skub Pages page where you can look for um yeah functions that um yeah some stats on different functions and check which um functions are essentially affected by the e but you give you some

background so EAP 7623 is basically proposing to raise the the costs for call data so basically increasing it from four gas per Zer byte and 16 gas per nonzero P by to 48 for nonzero bytes and 16 I think now yeah or 12 I I I would have to check it again but definitely increasing it for both and the rational behind this change would be to just lower the maximum possible block size and I thought it might be um important to also introduce this EAP specifically

here in the rollup call because in the end it's the rollups that are currently the biggest call data um consumers and although most rollups have already switched towards using blobs there are still some rollups that are um dependent on cheap call data um I guess until P pectra most of the rollups might have moved to using blops anyway but yeah there are still some edge cases where certain rollups might still need to use call data especially if you need that call data inside DVM if you want to do something with it then those rollups might be affected and although the EAP is currently not considered for pectra I

think there's still uh a way for the EAP to make it into the into the update so um I'm super curious about opinions on it um basically what the EAP does is it introduces a floor price when you use use a certain amount of gas on evm computation you don't hit that floor price which means you get the call data at the same price as of now which is 4 and 16 gas per BTE but if you're uh pure data availability consumer on lay one L one then you might have to pay more for that and this allows us to reduce the block size from currently 3.5 megabyte

including blops now to a around 1.9 megabyte so it's it's almost halfing the block size here and why do we want to reduce the maximum possible block size um that's one question you might ask and the reason is because the current block size is quite large so 3.5 megabyte is arguably quite uh large and while the current block size is around um the average block size is around 100 to 200 kilobytes so there is a big room between let's say 200 kilobytes and 3.5 meab megabytes and in order to get to such a 3.5 megabyte block you would basically

um create one single transaction with a lot of call data and yeah get it into a block so there is no real use case except for creating this very very big transactions that yeah I I'm not aware of any use case and there weren't such big transactions that really consume the whole gas um that is available in the block within one transaction so in my opinion it makes sense to make sure that the block size um is reduced a bit and yeah Paving the way for further scaling because there as you might have seen there are already there's a draft dip I think for increasing the blob

count and there is also pump the gas.org which is kind of a community effort to increase the the gas limit and I think this should be um taken very seriously because I think the the community has voiced um yeah a demand to increase the gas limit and yeah we can we can discuss if it if there is room so probably the cord um can tell us if there is room to increase the gas limit without changing anything in the call data because of course the the bigger the gas limit the more cold data you can get into one block and the bigger the blocks are so

yeah curious what what people think about that I think there were already some some cords saying okay we shouldn't um naively increase the the block gas limit because we already have very large blocks and then of course the question is how do we best deal with the block size EAP 7623 is one attempt um I've not heard about other attempts to to achieve the same goal but of course there there might be different ways towards towards that goal and yeah super curious what people think especially if you're representing a rollup if you're working for a rollup I'm super curious if this would even

affect you if this would um affect you as a rollup because most rollups I guess would be unaffected um entirely um yeah so curious what people think even if you're for it against it um I'm curious to hear about different opinions so assuming you've switched over to oh yeah yeah no I mean the roll up will choose between which is most cheap either call data or either blop so if

you increase the call data cost at the very end uh more rollups will move uh in order to put the data avilability into the blops I guess which is which is good right because the rollup data has kind of the better place for rollup data is is are the blops right so this might be a positive aspect to yeah kind yeah kind of forcing to switch which is I mean it's not good no because at the very end uh no not good because you're forcings to move to

blocks but uh I mean if it's not forcing in the short time I think it's better uh maybe in the midterm it would be better for rollups in order to adapt perfectly to the to the blocks so this the the Threshold at which you do sufficient compute such that the co data cost isn't at this higher level um would we be reaching that threshold with for example a fraud proof or does this mean that fraud proofs um would become more expensive you have any insight into that um actually you you would have to

tell me how much call data such fraud proofs need because um I can tell you that it's around 97% of the transactions would be unaffected so this means um there are not many transactions currently that would be affected I know that there are some very big miracle proofs that might be affected by that because certain Miracle proofs they don't use a lot of evm operations evm computation but they require very big call data input that are then of course used inside DVM um yeah I'm not sure about fraud proofs I guess as soon as you use the evm um yeah as soon as your transaction

involves the evm to to a certain extent so I think it's it's 2x so you have to spend 2x the amount on evm gas um 2x the amount of gas on evm computation compared to C data then you're already in that that range where you um don't hit the floor and currently it's around it's as said 97% of the transactions um of last week would be unaffected and those 3% of the transactions that would be affected were executed by 1% of the users so the the number of users that are affected is very small um currently I think scroll hasn't switched to using blops what I

saw so they would still be they would at the if if we would ship that today they would be affected and also um Stark net so I'm not sure if someone from Stark net is here but I think also um the Stark proofs they are very big and they also need those um need that data the call data inside AVM so not sure if there is something to optimize um or if there is another way for them but um as soon as you require a lot of call data but you only touch the evm a little bit then you are affected and also maybe to add that most

of the affected users today would be those that add messages to their transactions so if you withdraw from some exchange and the exchange lets you put in a message in your call data um you might have seen that um then you you're affected but only very negligible because the messages are usually very small so this is not a big concern it's more those that have very big call data and still need it inside AVM so what about future um uh use cases where you're using a lot of CK proofs that you need to include in the

call data like not you know that they're they're different that you know sufficiently different that it's it's uh um that it's uh um it's not good for for aggregation and um uh recursive proving so what do you do then are you thinking of ZK co-processors like uh axium aotus or lag range no just in a in a in a in a regular let's say let's say a a like a um a defi use case where you want to do trades right or more you know more complex trades and you want to make sure

that you're um that the trades are compliant and you're using Z knowledge proofs um as assertions that that you know sender recipients um Etc are proper um um are are are uh properly kycs um that the assets that are being traded are not hitting any any asset policies um you know maximum volume of of trading per day um suitability for example is the is the um is the is the is the account purchasing um that suitable for that type of asset um that's a compliance thing right it's

like if that account belongs you know if it's a highly speculative asset and the account belongs to um a 95 year old that's not suitable right so you have to have these you have to have these ways to prove that and the easiest way to do that without revealing um information if you want to do it on chain whether that's L1 or L2 doesn't matter is using gks so um there is there are there are use cases where you could have you know eight um 10 different uh zks um in um for um for a single um defi

trade okay yeah I see yeah usually if you use snarks for example then um in in all the cases I saw so far um you're not affected because it's just so much evm computation that you need to verify snark that there's a difference for Starks so I think when it comes to input it depends on the on the inputs right I mean inputs could be could be uh could be um they can depending on what the inputs are how many there are that um will drive call data size um things like that right but yeah as you say it's dependent on the input how much

input such use cases would eventually need um I don't know if you look at tornado cach for example today um the inputs are kind are small enough to not hit the floor because it's I think torado cash has 500k gas the one transaction so deposit or withdrawal is 500 gas while the inputs I think you have I don't know five six parameters that you need in your call data so this is still not enough to to cause cause um causing hitting the floor yeah I'm I'm looking use cases where they're they're they're you know

unless you're going to to like a like a semi-private approach um where you with the input is just the root um the root hash um you have you could easily have 40 50 60 input parameter right and that's also because you right because you have different keys and you know when you de compol so it's like it's it's it's there are there are use cases where you have you have where you can have um large number of of public inputs MH yeah I see I see I see that point is it's very similar to the big Merkel proof point where you also need to provide the whole path um yeah I

think it's a it's a very individual thing so one would have to look into the individual transaction to check if they would be affected or not maybe to to highlight those use cases will not become impossible right they would just become more expensive expensive yeah and for example with with Starks I think it was um around 30% more gas so a star proof would would be 30% more gas for example and of course this could be compensated by increasing the blop count by increasing the gas limit by just making the whole thing cheaper but this is of course um a

little yeah this is an unknown so I can we cannot really but that's a no I just wanted to bring that up as a as a as another use case which is kind of general what if you're using what if you you're dealing with a lot of um a lot of snarks which I think we're going to see more and more of yes I I agreed to that yeah I to to um highlight that again there is this there is this I think the the third link I posted shows you all the functions and there you can see which functions are currently affected

and you can see it's it's functions like commit batch which is a function used by scroll which is currently affected and would be increased by 100% and others are like um there are mint functions but they are rarely used um for example there are other functions like verify Merle which takes um four lists two lists of U 265 which might be affected and of course the verify F which is the the function that starware uses and so on that link if you're a roll operator you can check if functions that you call if they would be

affected but um so far what I have seen um it's only starware that will still be um affected because all the other rollups um can kind of flee towards using blobs and I see Ana wrote something let me check yeah Ana wrote um now that we have blobs they call data increase Sims inevitable um expensive right yeah I agree ana um CK proofs in general snarks are um usually very small like tornado cache and they come with

the verification takes a lot of AVM um oper resources so snars that we like we know them today like torado care for example they wouldn't be affected at all so they are way above this threshold using enough evm um operations to do um regarding your option four uh full uh 2D pricing for cold data with a market similar to EIP 1559 I assume this one is um uh not uh scheduled because this is too complex to implement um for Petra Which is less than six months is from

now I assume yeah so this was also the the main feedback I got so far regarding that point that kind of having a a separate fee market for call data might be just an an overkill for the for the thing we want to achieve which is basically just lowering the maximum possible block size to prevent those attacks and yeah so of course having a separate fee Market would be also a very clean solution but maybe just um over engineering the whole thing or too complex I think ano once had this this comment like why don't we just have a separate fee marking for fee market for every up

code then which might be the yeah the next step I think when roll up like two years or three years ago there all rollups were discussing uh 2D fee Market um if you search on if research uh there might be several instances so there might be for it but the burden of implementation is on um the execution layer and uh we need uh Buy in from them uh for this and then you need also um wallets to implement this so I think uh six months is is way too low and if are like

it would be very interesting uh but uh if we want something for um Petra we need a a smaller solution and then the question is is it good enough or we we need yet another artwork to fix this again right yeah I agree yeah fully agree and it it would also be the the question would then be do we then achieve the goal of lowering of reducing the block size right because imagine all rollups um switch towards blops then call data becomes cheaper again and suddenly with cheap call data one could again create those very big blocks that might cause some troubles

especially thinking of um yeah smaller smaller stakers that cannot that don't have the bandwidth to keep up but this is super interesting would be cool if you could send me a link or something I would I would love to see that discussion I I haven't seen that so far unar yeah on this topic I just wanted to briefly mention there's nothing right actionable right now but I was also working on like multi-dimensional fee markets uh like a year and a half ago or something for for for a while and uh and in general kind of more repricing

flexibility I think there's a lot of pent up demand around doing this especially as where2 structurally become less and less similar to L1 especially in just throughput numbers um you might have seen the kind of for example Bas has been very active on like meing about wanting to like 400x the throughput um but but I know that a lot of ler twos are working on similar plans in the background um once you do that you basically just hit very different constraints than L1 and so basically having the exact same pricing schedule even if you stay on a on a one-dimensional pricing scheme just doesn't make sense so basically the question on how can we have more flexibility in like having different pricing schedules for different VMS without breaking interoperability of

apps um how can we maybe introduce multi-dimensional pricing there's a lot of kind of just pent up ideas and research and everything I would expect that over the next one to two to three years this world somehow lead to some more fundamental revamp of the fee market and some actionable things for maybe just for their TW maybe also for their one um so for me in my mind basically we are in this space where right now we are just trying to have like small minimum minimum intrusive adjustments that basically get us to to this more fundamental uh rework and and and I think basically Tony CIP is is perfect for that right um anyone else want to

mention anything on this EIP before we move forward maybe if someone is very strongly against it um especially including it into Petra I will also present the the and propose it to include it into Petra tomorrow in the all call so yeah just feel free to join and raise your um your voice there if you if you don't want to see it into pectra um or contact me I'm happy to discuss it thanks Tony um maybe uh ping uh

people from um ZK co-processors I'm not sure how they use C data but they might need a lot of data as well okay yeah thanks thanks for that input great and then I believe mommy also wanted to talk about EIP 7667 uh which an EIP to increase the uh gas cost of uh hashing pre- compiles M yeah so uh vital proposed uh two weeks

ago uh to increase gas cost of Ash functions um obviously uh for uh type one uh uh rollups uh that's uh great because uh hash functions have a disproportionate proving cost um but I'm I'm wondering uh like should we just say yeah all rollups agree with this uh that's basically the kind of consensus I'm looking into uh because I assume over uh daps developer for example uh for example the one that use Mel trees

on chain we say oh no this becomes uh too expensive for us and there will need to be a discussion and Arbitrage uh in terms of uh do we increase 2x 3x 5x uh or do nothing for example I think the thing I'm a little unclear on is why uh like from an L1 perspective more than obviously is this this benefit for for uh type one l2s uh but from L one

perspective why is it something that needs to be done now as opposed to in the future uh so that was uh asked uh by uh wgm elements um and what did V apply um yeah making things um unviable uh and so that they uh come to other Solutions before uh instead of uh them building something and then uh

one year later um it's it cannot be it it's dead in the water so I guess it's managing expectations uh personally I I have no um opinion on when um when to do this yeah I mean I can definitely see the

argument for wanting to do it sooner from from the perspective of setting expectations it would pres prevent um yeah issues where people are unduly impacted such as Tony was mentioning earlier with with hisp um where certain use cases suddenly get become radically less possible or more possible anyone else want to raise any additional points on this EIP uh no that's all just uh raising awareness uh and uh seeing if there is some kind of consensus on rollups or if people

maybe don't care neutral would it not make sense to to offer the option I mean in inrease the cost on the L2 rather than the L1 right and for for for you know P cheack um and offer an alternative on the L2 like posidon to um right because from a from a from a smart contract point of view if you're using hashing hashing is hashing is hashing right as far as the you know logic goes right um obviously from a proving point of view that's there's a there's huge difference so if you just

make it you just introduce different pricing for hey if you use pack well that's going to cost you like 10x more or 20x more than if you're using like posidon two we also have a pre compile that that's about that I think that's uh that's very interesting point uh you I think you should add it uh maybe it should come with um a posit on hash function for uh based on both BN 254 and maybe one for uh for uh BLS 12381 yeah um isn't isn't doesn't pan to work like

effectively very effectively for both uh yeah yeah but uh maybe we should have uh ANP that implements both uh so that people po are not again oh there is only POS on um on BN so I'll build only BN oh yeah of course of course of course of course yeah is the idea to have this thing as a pre-compile yeah so you so you give options right you give options for the for the smart for the smart contract devs it's like look you do this costum money it's more

like way you're used to but if you're writing code for an L2 you know and and and by the way it would not hurt if you had if you had pre- compiles for for like posidon 2 on BN and and BLS on the l12 because that would make um that would make uh um that would make life um easier for you know uh for ZK type applications right because then you can you can compute posidon hashes on L1 that you might need for you know public

inputs Etc so that there there's there there's also there's also a general upside if you want to make the L1 more ZK friendly um to support you know something like piden on VN and BLS I I imagine the issue of getting this kind of thing on L1 will be the relative novelty of uh Poseidon um I just pick Poseidon other half you know sure sure sure but but it's like it's like you would have to you would have to discuss which is the which is the the um which would be the type of has function that would be um that would

be supported because that basically would become a forcing function right sure but I mean it's it's a more General issue of um uh arithmetic hash functions yes like their relative novelty and they like these are things we have to maintain in perpetuity um on on the all side um yeah yeah it's doubtful that that that that's going to go away but point right yeah sure if you if you want to to and I said you can do two they're not they are not coupled right you can do just the stuff on the L2 and not do

it on the L1 and do the L1 later um but for offering something like that on the L2 would definitely lessen the pressure um on on um on the l2s if if you gave the developers the options yep no agreed all those things are relevant and that's Lally why we set up the SCS to be able to ship these kinds of things on al2s that might be necessary um but l1's not necessarily L1 isn't necessarily ready or willing to ship

great I think that brings us into General disc question does anyone have any other points that they wish to raise yeah so um I would just wanted to to uh bring up a point since we had discussed like um L2 transaction fees so the L2 um standless working group over noasis has uh come up with a proposal for for an API spec and I thought it might be um a good time to have a breakout session on that with like uh the different client teams to take a look at it and what see what they think um um because it would be aligns with

like you know separating out the fees in the different components Etc execution fee data fee priority fee what already has been discussed so I just want to propose that and see if people would be interested yeah I mean actually imagine that's the kind of thing that there is demand for um and you're always welcome to host uh your your own record on this any other topics maybe just to briefly mention um

what and Andreas just said I think basically that just um to add I think basically the two separate aspects of the EXO protocol changes like having some sort of consistent transaction type for this and then the the API changes around this and I think ideally an ideal kind of approach would combine the two but of course any protocol changes would require much more Buy in from the different teams to move to to to new kind of transaction type system so um I think on the raw call side a breakout would probably be good once we can kind kind of have some sort of feeling for how to best tackle the um the actual kind of in protocol changes as well um but I'm definitely open to also having a

uh at some point having some sort of breakout session on on more the the API changes stand alone otherwise because otherwise maybe it's not a good idea to to have them blocked by by by a need for forign protocol changes yeah I I think they they um I mean the the the apis are simple enough that they should you know all that information should be available so it's it's I don't think that there would be like I mean might be different for for each client but I wouldn't perceive that there should be like any protocol

changes on the on the client side right the data is being comput it today so it's just a question of exposing that right yeah I'll have a look and see whether that makes sense to have like some sort of roll call kind of organized um breakout I can I can chat with you about that but um then we can maybe yeah uh have something announced next roll call and and have it then kind of in the cycle after um or otherwise alternatively maybe have something more on the Oasis side and then we just highlight it on roll call or something either either way physically but have

follow next roll call yeah so we we we have we have I mean we're basically ready to say hey this is a proposal like what do you guys think we're we're we're at that point so was like with like you know Mets and offchain and and optimism and so forth sounds good sounds good okay cool and then because you was Al asking about other topics so there was just one topic I briefly wanted to mention um and that's more like on on a meta level just for people um to kind of maybe think a

little bit about uh kind of the general kind of future role of of of roll call um so so so K and and I and and you have we've we've been kind of talking about this as well um o over the last past few months um and and maybe so just for context for other people so the way I see it is that broko kind of of course started as a bit of an experimental um um project and I think by now the I see three separate distinct kind of categories of uses for for for this process shaping out and so the first one would be just a general connective tissue between layer one and Layer Two so that's like a little bit like what we saw today the conversation around the call data EIP BLS cips that

kind of thing so basically both representing layer one towards layer twos and the other way around representing layer twos towards layer one making sure that everyone is kind of tied into the the respective kind of governance processes um and and we have less friction there um so so that's kind of that's kind of number one and I feel like we already kind of on a good path there in terms of filling filling that that kind of Gap a little bit H then the the the the second one is what I would say is going be more General kind of I would say research that's things like fee markets everything I feel like there that we had the the breakout calls which were a little bit more experiments of course we haven't really followed up on those yet because General feedback was that Weekly calls was a bit much so

the question is do we keep that up in the future basically where where is there a need for say kind of cross layer to research collaboration so that's a little bit something where we are still kind of evaluating and so if people have feedback like where these initial breakout calls we had a few months ago with useful do people would people want to to basically and start that back up and that's definitely something that that we'd be be interested in hearing about and then the the third one that's I think the most ambitious side of of the future for roll call would be um what I would I would say is well on the one hand to say just like Layer Two erc's or something that's of course something we can we can do at any time that's something like this um fee Market API change or something but but I think

even more interesting of course would be the ipce so potential future extensions of the evm on layer 2 and I think there the the this the situation we are in right now is that so far it it is shown to be and that was of course predictable it's shown to be relatively hard to ship any kind of changes that that meaningfully deviate from layer one just because for now there is no good process of having support for these kind of changes in in clients for forus and so for now we are really limited to these IPS like the R1 a pre compile which happened to be so tiny implementation wise that that g in this case um just opted to support this

even even while it's not actively targeting layer one yet or at least not accepted for layer one but of course that's an anomaly most lay most interesting Layer Two IPS would would require deeper changes and it's not clear yet in what form this could be shipped so I think for now basically the roll call is a little bit and I don't want to say blocked but basically it's it's we in a position where where we yet have to figure out a good path we have we have some ideas there it's maybe too too early to really discuss those but that's definely topics for future breakout calls so far we have talked to individual client teams about how kind of a path forward to to giving more more options more more more more possibilities of of these kind of more ambitious um IPS uh in the future and

we're also over the next few weeks going to start talking more to to some of you all on the on the layer two team side um um and so I just wanted to bring bring it up already just to because I think these calls for now you know there also like if you look there's been attendance is relatively low and everything because right now it's a little bit still in this experimental stage um and so we're kind of actively working on on on charting like a more like a path forward to to figuring out exactly kind of the the shape of of of roll call I just wanted to mention it a of of course if someone has feedback right now but also more just to think about it and um we we'll basically kind of reach out talk talk to teams and um yeah I think I think the ambition is

basically to to figure out how this this process can be the the most useful for you all so just wanted to to get that as like some some context so SC you want have anything else they want to add to that or uh bra more generally as discussion before you wrap up okay great thank you everyone for attending I will see yall in the chats thank you

cheers thank you byebye thank you byebye