Stateless Implementers Call #30

Transcript

okay um so welcome everyone this is call number 30 uh from the state implementor school so I will share the current agenda in the chat so uh to give an overall uh overview of the agenda we have the usual team updates uh then I will give a brief overview of the current binary tree EIP draft then we have some topics around um 4762 uh one of them is atomicity of C changes which is a point raised by the GU team then we have uh account version

question uh which is related on how to identify 77 or2 and EF accounts in the tree and yeah we just want to mention a new website that is stateless team uh created for for more um um divulgation of uh stateless efforts and if there's time for it uh I can also present a bit some work around prage generation but maybe we'll leave that for the next call so regarding team updates um I know if anyone wants to start um

start with U ethereum JS so in the past two weeks with TR and developments we've uh made some effort to implement an early binary to Binary trees implementation uh so this can serve as a testing ground and also uh as a an early implementation if we end up choosing that as a way forward so the binary trees impl mentation is pretty much uh done we would be able to get it finalized this week and and merg it in the the the actual repo uh and yeah maybe gender can share other updates but I don't think we've done

much in terms of a the current verical test net on Bas side I can give some updates so we are still working on the modification of bizu in order to have an evm version working for stateless so I'm modifying the get Cod part of bzu because today when we are running a smart contract we need to have all of the code directly but I need to refactor this part in order to be able to just have fragment of the code uh I think it will be maybe

the last modification in the evm part before having a version of Biz that can run with the stess mode um only for running Toma is also working on the proof uh verification maybe Tom if you want to share some updates yeah not nothing new Under the Sun it's uh implementing the verification the verification uh for for the proof um which requires sying a few a few libraries to together I me we have the the native part and and the um and

the Java part to Sy and there are some modifications on both sides but it's not uh it's on the way it's it's it's uh it should be soon uh working and um and we'll be able to integrate on the on the test net I think it's all for cool so I can also share some updates um so yeah a lot of it happened since our last call but I created this um p 3 draft uh it also has a python implementation I will share

later and I think also Gom has been working on upstreaming many of the work of many of the 4762 IPS into G which will help on some reasing work for future Dev Nets um I know gam if you want to add something else uh not really I mean we're going to present uh some some things we talked about but it's it's mostly been writing documentation in the last in the last few weeks cool um somebody else want to share team updates if not we can jump to the next item in the

agenda okay uh so the next item is um I will give some overview of this binary tree IP which I guess a lot of people here already know about so might not be entirely new so I will share a bit the screen to um help with the [Music] explanation give me a second okay so hopefully people can see the screen um let's start a bit with what is the

motivation for this proposal uh because it's quite relevant so in the last year there were some important um news regarding okay so I will say that the argument the motivation for the CIP Falls probably in two main buckets the the first bucket is um Quantum security concerns started to raise a bit more um motivated by some breakthroughs um coming from Google early last year um and that continued to happen later to last year so there's yeah refresh

concerns about how seriously we should consider this um because Burl trees introduced uh some Quantum ands safe um components into the protocol uh related to using elliptic curves and elliptic curves are in safe so we will be um yeah depending on the estimation on when quantum computers may become real and this might be a real risk maybe the return on investment of actually introducing veral trees in the protocol might not uh be the expected one

so um there is a lot of discussion about how to interpret these new breakthroughs uh the research team has started um uh a lot of efforts into analyzing like how we should change the protocol for existing constructs that are in Quantum secure uh so there there's recently some work around signature aggregation and many other things so um I know that there are a lot of people that maybe think that this isn't something that we should um care about or at least not in thinking that this will happen in 10 or

15 years but in any case um this is like a new relevant Factor because um I think it wouldn't be con that yeah we introduce new constructs that are in Quantum safe uh and that seems to be a rule that many people will think would be the right one um as you think about protocol changes the second bucket is um proven systems for um snarks have been improving their performance by uh big factor and that is continuing to happen so um in the case of stries the main

important case is how fast you can prove hash functions uh of course the performance depends on which hash functions you use um the reality today is that the only um hash functions that we the only hash function that we can use for Tre merization is poson two um because it's the only hash function in which current improving systems can deploy um the can can prooved um with a throughput that we need for layer one um the complication here is that posidon 2 is not still considering

secure for layer one uh there are many layer twos that are using it uh for quite a few years uh but well layer twos can take other kind of risks um compared to layer one so um the the research team has um launched some new efforts in trying to assess more formally the security of posidon 2 which you can you can see in this website if you are interested um this posidon crypto analysis initiative this is an effort that will probably take one year and a half or

two um so there is still some um time to really gain confidence and yes ideally is the the hash function that we should use for for a new state tree so coming back to um The Proposal the idea here is to say okay maybe these two factors uh are good arguments to reconsider the usage of burle trees um so what we can do as an alternative and the most obvious option is using binary trees which is not a new um idea many years

ago um vial and Gom has worked on this uh for a while um but at that point in time proving performance on snarks didn't even I mean was basically impossible and Quantum concerns weren't really that uh important either so yeah that's how work trees appear into the scene so the idea of of the CIP is basically pulling a lot of ideas from Burl reg regarding how you encode data in the tree so I think this diagram mainly summarizes how this

works so the idea here is that um we do the same account um data encoding into the tree the same stage storage slot grouping um and the same um called chuning as we did in Burl so the overall shape of the tree is the same the only thing that changes is basically um how um you basically um create these internal nodes and how you meriz the tree so for the people in this call this

basically means that it's the same idea as sple but instead of having this uh vectors for doing commitments in the nodes you simply have a binary tree with a hash um so that's kind of the tldr uh of course which which hash function you use for merization uh is still under consideration regarding all this stuff I I said uh regarding posidon 2 or Blake three or whatever but the good part is that you can implement this CIP just with an an abstraction about the hash function and if we want to start with Blake three because that's

easier for clients because in every language we already have uh implementation of that we can start that way and if later we figure out that posidon 2 is secure doing that change in the AP should be rather simple and W have like a big impact in in in existing implementations so uh this is mainly to say that all these posidon 2 uh evaluations shouldn't be blocking anyone trying to make progress on this um so basically um yeah you use the the new hash function for merization I use the hash

function for the tree key generation which creates this um stems as we had in bural that's kind of the same and in the St you basically encode um 256 values in a vector uh but this Vector instead of using um person hashes or person commitments as before you create a Merkle tree uh in this like sub tree here at the bottom so the idea is pretty much the same um the has a python implementation of how this will work um compared to veral Tre is quite

simple um because it you only uses hash functions doesn't have to introduce any new elliptic curve and things like that and that's basically it the rest of thep regarding tree embedding and cold chuning and all that is the same basic almost the same as bural um so I don't think it's worth diving too much into that um and yeah in the rational there are some sections here uh which might not be entirely surprising because they also apply Tob barle the St friendliness and post Quantum security is basically what I

explained at the start of the of this explanation um the tree having an arity of two versus having a higher arity it's basically trying to highlight that if you use non snark State proofs so like simple Merkle proofs having an arity of two is what minimizes the size of the proof which is still useful because it doesn't mean that everybody that uh will create State proofs will use snarks uh we use we need snarks for the for the block execution State proof but for if you have to prove less uh leaves you might prefer to

Simply do a Merle proof which is going to be much faster and smaller so that's this is quite relevant for probably stateless pools or um if we have inclusion list and we have to introduce the um a state proof with the required data for transaction validation probably that will be with a simple Market proof and not really a stark or snark and also there's a small section regarding how State expiry could work in this tree and that mainly depends on what state expiry strategy we have but if we apply if we try to apply

EAP 7736 to this three we can still make some changes to the sign such that we can apply that same idea that work for Bal and yeah that's basically it uh in the IP there's a link to this repo which has a python implementation so if you want to take a look there are some really simple test cases there uh so yeah if you want to T add some entries and compare the root hash maybe that's useful I'll look at the tests in this repo and I also did some really simple um rust implementations just to check

that it matches the python expected roots for these test cases um and this um ribo also has some hash bench crate where um I kind of Benchmark some potential hash functions out of circuit performance so if you want to look at that you can simply do cargo bench in this repo but to share some numbers um I can share this in the chat soon um you can see like Benchmark for Blake three Kack uh posidon 2 under different fields um as you have a sense for your clients okay if we use posidon

2 which is probably the slowest option out of circuit what does this mean really um so yeah I will wrap it there and yeah I know if anyone want to have some question or make any comments yes MOS um is it safe to say that we are not shipping workl and that we are actually going with binary trees or is that still not fully decided right that's an excellent question so uh unfortunately the answer isn't

100% I mean we cannot really know for sure uh my opinion around this is verle has lower and lower chances of happening uh to really reach any meaningful conclusion I mean we will need some ACD discussions about this but I would say that all also depends which other L1 changes we do in the protocol before a state three conversion because if we include other changes like delayed execution pay execution and um other things um there are two things there the first one is as as more time passes before we do a state three change the

clock is sticking for Bal and Quantum risk because more time passes and the risk of a quantum computer happening gets closer so the return on investment is quite inconvenient and the other thing is that um having more time to create the proofs uh makes even more viable to use uh snarks for State proofs compared to today where you have like one or two seconds to create the snark uh if we do all our changes in the protocol maybe you have seven or eight seconds which is a huge difference so um yeah my summary will be that most probably um binary has

higher chances on Burl uh but yeah of course I cannot really say for sure because depends on what the community decides yeah yeah just to add so while I'm not going to disagree with you like binary does have these days more chances than veral um veral is still the only option that works currently like binary assumes some progress in terms of uh proof performance and things like this or a complete redesign of core parts of the protocol So currently uh while like what ignasio was saying it's it's pretty easy to implement this uh the

CIP uh it's not that different from from the veral from the veral uh design um I think it's still currently the the smartest thing is to be cautious although yeah like I said no denying there's a lot of momentum behind binary trees but simply don't forget currently there's no proof no clear winner in terms of proof system so that means if you implement binary trees today you're stuck with Miracle proofs which are much larger um so yeah I I would say currently the best option is to wait and see that's uh yeah that's the best way you can put it I

think yeah and I want to add something that I think gajinder is trying to highlight so the EIP doesn't really introduce any and try improving system and I think um the main goal will be to not really do that even so um yeah I think I think for binary trees while it's true that today we don't have the required improving performance unless we use posidon 2 of course um maybe it's not something that important BEC I mean it kind of depends when the state treat change happens right if it is happening one or two years well that's like one or two years for of time to really make that happen

right but I agree that if we someone asked if we deploy this tomorrow is this avable option the answer is no but we it seems pretty clear that changing the state Tre in the next fork or the other probably won't happen yeah um I think oh yeah Karim but he ler his hand

um s could you hear yeah yeah so I just wanted to say when Gom is saying wait and see so you say that uh we not Implement binary tree for the moment or we we still implement it and maybe in the next Vel devet we will use it or maybe we'll have two devet using to defund uh three structure or something like just to to know what we want to do for the next month uh yeah so for the next month or at least my suggestion I'm not the one deciding for everybody here um but my suggestion for the next next month is to keep doing veral uh because we would like to launch a new test net

with field cost activated and rebased I said on on the on the stess channel I said Canon but actually it would be good to have Petra that means we also need to implement 77 2 so I I started working on an EIP update to support 7702 but it's not quite complete yet uh so that means we already have a ton of things to cover uh and like I mean like I said and like ignasio said before me we have uh it's pretty easy to change right the this whole EIP has been designed so it's easy to uh make it a drop in replacement with uh like you take the veral tree out you drop in the binary tree everything work more or less the

same except the question of the proof which is why I'm saying wait and see but if you want to I mean um so wait yeah what I'm saying is the next the next devet will will most likely be a veral devet um but that that will also most likely be the last one okay um and uh yeah so it makes no sense in my view to rush implementing the CIP I mean um etherum JS has done it very good uh we want to do it for GU as well um but I would say currently in terms of pure uh interrupt and everything I think it's

not it's not the most urgent thing because if we rush and choose something to as the proof system we will probably have it uh have the the rug pulled underneath us again so I would I would suggest just waiting uh waiting out for you know the whole Poseidon question to to settle uh to settle because if we use binary trees what hash function function are we going to use Poseidon Blake three we don't really know at this point what uh what proof system are we going to use um are we going to use uh some form of of you know Circle Stark some form of Bas some form of uh of we don't know what okay do we even bother uh attaching

the proof to the block there's there's plenty of open questions so I would say currently in the in the spirit of stability I think keeping veral for the next Dev net and figuring out the other questions that will necessarily arise given the complexity of the change um yeah like we keep veral and then we uh we take our time to to design the like finish the you know getting all the other details of the EIP right and then we do uh hopefully this year but uh we uh yeah it would be it would be better to just uh not like like I said don't don't rush to Don't drop veral from your

code base just yet because uh yeah it might uh it might come back and be useful unlikely but it's definitely going to be useful for the next Dev n okay sir right so so as a summary uh it is worth highlighting that uh the state Tre is quite independent from 4762 so uh and also the State Rec conversion right because the State Rec conversion efforts uh it's independent of the targetry um so actually there's a lot of stuff that we will keep anyway and we can still make progress so Asam said like the next DEET is probably trying to Target implementing field costs of 4762 which is independent of

the state tree and we can also work on state Tre conversions Dev net which is also independent for the state Tre and whenever we want to implement binary we can actually use B three without proofs in the blocks and we can still make a DEET for that so that would me but that will make a lot of sense without being blocked by those things too and we can later switch the hash function um because yes I don't you thing apart from the security we have to decide on some particular file fin field which I know there's like an hold there but um it shouldn't be hard to really make that change so we can

actually um create a DEET for binary without proofs and like three and that would be pretty good um okay so the next item is I will stop sharing the screen the next item is this um atomicity when charging gas cost in 4762 uh this was a concern a proposal from the guest team so maybe you want to present this topic uh sure I will also share my screen because I slept together a quick presentation um is that the one uh yes okay so to give you some context I've been like

ignasio said earlier I've been trying to get the guest cost into guest master um so I'm getting U I'm getting close to this but there's been some useful feedback that that came that came back from the from the guest team team and they were asking for a change that in my view makes complete sense or at least if it doesn't make sense I completely lost uh I completely lost the reasoning behind it and so I'm going to explain what we do currently um using this uh these slides which hopefully are understandable even though they were done five minutes ago um and the way it happens is imagine you have a witness right at the beginning when you execute an uh imagine

you're you're executing an instruction that is accessing two Fields like the basic data and the code hash um imagine I mean at the beginning the witness is empty which is why you have something that says witness with an empty uh an empty box and what you do is you start with the initial value of gas which I call gas Z zero and you check if it's uh more than 2100 um if it is more than 2100 then you compute the new value for gas one uh which is the old value of the gas with gas zero to which you reduce the sorry from which you

subtract uh 19900 for the branch access and uh 200 for the for the trunk or Leaf access so those this value should be should be familiar to everybody um ask me to EXP and if it's not um and then if you so if you have enough gas basically you go on right if you don't you revert so the gas is set to zero you consume it and you revert so that means your end witness is empty like the M your witness will not contain anything anything in it uh now assuming everything went right you add the basically the basic data Leaf to the

witness and then you go again you check if the gas that you have is more than 200 you already open the branch like the the group so now accessing a new chunk is only a 200 uh a 200 gas cost if you do have this gas cost then you subtract 200 from uh from your gas pool and you continue if you don't you revert and you set your gas to zero you consume the leftover gas which is less than 200 and you revert uh and so the Final witness if you do this will contain the basic data but will not contain the the code hash um which is basically what we want

to get rid of now if everything went fine your witness your uh Final witness contains the basic data and contains the code hash leaf and you continue with um the two like the gas that go sub subtracted in two steps so uh the total value is a what it was before the start of the exec the instruction minus 2300 now what we want to do is make this Atomic so redu like remove the the middle um the middle step so what is proposed is that from the start you check if you have the 2300 available if you don't you revert

and if you do you you subtract 2300 from the initial gas and then you have uh directly the two values in your in your witness and you you return the you return still the same value as you would have before in case of a successful of of a successful execution but there's only two possible uh ways to witness uh changes either it does not change at all because you have a revert or it changes with all the leaves in an atomic way um I think it's actually much uh simpler

at least it would simplify the GU code base a lot um I would like to know what you think of this like did I forget something like is there a good reason not to do this um Tanish I know said it was going to be more complicated in never mind I'm quite curious why that is um and yeah like um just asking for example yeah ejs B if um or anybody else if if they think we should not do this um yeah that's basically the IDE gist of the idea

yeah uh I have a so this is just for like a single sub or let's say like for example uh but right now we don't charge like dash for transaction like sender and receiver but let's say there's a case where there are two addresses and you address what like for one address there is one sub and the other address is another sub so do you want to charge everything automically or just for one single sub right so yeah uh no so it's not everything atomically and a notable use case for what you Des cribe I think is the create right because in the create you first touch um the account in read mode and then you touch it in uh in right mode and then you release you

deploy the code so if any of those steps fail um the behavior would still be the same like for example you uh you fail at uh deploying the code then the account is still created and it should because this is a case that without if uh like without all those uh EIP 4762 consideration would still be the case like you want to if your code deployment fails uh the account is still created but the code is not present that's already something that happens yeah um ignasio I guess yes so regarding the

implementation regarding like saying the simplified get implementation yeah I guess I trust that I mean I see I think this complicates the implementation actually and also complicates the spec because today the spec doesn't have to even explain this atomicity Dimension today in the spec we simply Define the rules for including accesses into the witness and the atomicity is implicit on each item that we include so actually doing this change means that we have to explain this atomicity in this spec uh which I think maybe it complicates

things a bit more um but yeah I would't say this is a strong push back but maybe just want to highlight that maybe this complicates a bit more to spec because we have to actually explain this U that's a fair point this being said I disagree that the spec I mean the spec is completely neutral it doesn't really say if it's Atomic or not like it says when you do this uh emit those events but it doesn't say anything whether it should be um it should be done together or not um but it should right because if it doesn't explain this how an implementor really know how to do this and not have a consensus about well

the the same um I mean yes it should definitely uh specify it um if you if you like the way it was T received by the guest team is when they looked at it and they were thinking in terms of access list in the model of access list what is first you ask for everything of course there's no such a granularity but the idea is that first you check the gas and then if you have this gas you add it to the access you add the account as a whole to an access list if you don't have uh this gas while you don't add the account to the access list and that's it um so I would say it's an interpretation that makes sense from uh the point of

view of someone who has never dealt with uh with EIP 4762 but did deal with the with access lists um so that's uh yeah I mean my interpretation of the EIP is as it currently is but I can totally see why uh the rest of the guest team looked at it and said well yeah uh this is how we understand it so I agree it should be um it should be specified but I don't think it complexifies the the EIP I think either way whatever we pick we choose it needs to be clarified in the EIP basically yeah okay I mean I think that

this point that you say about not having enough gas and then adding whatever you wanted to add is actually a rule that we already have right so this is more about a new situation of having to add more than one thing into the into the witness compared to access list where you always only add one thing because the whole account data is is like a single unit right yeah um yeah okay I mean you you might be correct that it's actually harder to implement uh it was just a discussion between me and um and Gary and other people Martin I think um I could

implement it and figure out if it is indeed simpler um yeah maybe it's just simpler to review maybe it's not going to be I would need to to dig and actually come with a line by line prove that this is simpler um I was just maybe is to I mean okay fine I I need to dig into this but uh Tanish I'm not sure if you understood what I meant like in terms of granularity basically is is that clear or yeah maybe a way to rephrase it before sorry before you answer is to say if a bunch of keys are accessed together in the spec then that's the level of

atomicity but in the case of create you have three steps those remain three steps so in your ideal example if you touch two accounts you would have everything concerning an account as an atomic operation and then everything touching the other account as the another Atomic operation but you would still be able to fail in the middle of uh those two things because uh those are two separate X aises if you will is that clear or yeah that that clear is my question uh uh but the reason uh I was saying this will be more complicated to implement in NE mind specifically I

think in jet as well like for example if you take a case let's say uh where you execute code copy and you're copying a huge chunk of code then like doing this automically means that you need to have like two like one copy of data where like you are checking that all the chunks are access and you have enough gas and then you add those chunks to the uh access not access list but the withd list that we maintain so that part is what I meant by it being more complicated but again like it's not a blocker from Le mind side as well like we can obviously Implement that if we agree to do this yeah so you're right in the case of the code copy if you if you copy a huge chunk of code um I mean yeah

I guess you would not copy any of the code to the witness while paying a significant amount of gas um um yeah I would say that's uh that feels unfair but it I think it would be simpler I might be wrong I need to implement it um my feeling is that it would be simpler but it would be a bit unfair that's true okay um let's move to the next item which is account version question which

to I think Um this can be summarized as um for 7702 accounts and eof accounts um we might need to have an efficient way of identifying that uh these accounts are fall to those cases so there's an idea on um encoding this information in the basic data Le um well that's one option and the other option is using the version field um so yeah this topic is basically about that maybe y you want to say something about it yeah not much than what you already said um I think

the people we talked to so far which was mostly Dan CR agreed that this should not be we should not use an AV verion field but I just wanted to run it by other people to figure out if uh if you guys feel that for eof or even for 7702 we should use an account field uh like set set a new account version um like one or two like for example one for 7702 and two for eof um there's a good argument not to do this I think I'm pretty much in line with the argument we should not do this we should just use the account hash or something else to to identify it but I wanted to know if there were uh people

disagreeing with this yep denish uh I would also prefer not using a new version but then the question is that like then what is the case when we start using the version field and if you don't have any case then I don't see a reason to include the version feed in general the three so what would be the use case it's a very far long-term use case might never happen but it would be for example using a different type of uh execution engine like if you have the native rollup thing using different virtual machines uh or

no virtual machine at all for example RIS five or um I mean yes if you most people will still run risk five in a VM but you know theoretically you don't have to if you're running on a risk FL Hardware um or people using move or svm or whatever wasm um that's when you would be using uh for example that would be a reason to use a different account version or uh if we use start having uh account types that are marketly different um anything to do with account abstraction and I don't mean 7702 account abstraction which in the grand scheme of thing is a bit of a hack you

just say well we're setting the code a different way but you're not fundamentally changing the way account works so think of it as a major upgrade to the account like the way ethereum sees sees its accounts um that's what we would be doing or maybe changing the you know the um the signature scheme or whatever this kind of a change something we so something to do for example with Quantum resistance flagging that an account hasn't been converted to a Quantum resistant uh um type of of thing so this is when we would do it so this is why we have the version the

versioning and it's true that changing the way the code is interpreted is not a major change compared to all the things I just described so that's when we would do it okay that makes sense I think then we should not use the version fi for this yeah another way to explain this at least from my perspective is the version field explains how to interpret these 256 values in the vector so it's basically that like version zero means that the first item is basic data with all this encoding in the CIP and the

item one is the call has but if in the future we want to have other kind of interpretation for account stamps let's say we should actually use the version for this um so I see more like a Tre semantics um versioning uh not really like encoding data uh to identify accounts which is more like an up up like more up into the stack um requirement um anyone else want to comment on this topic okay so the last item in the

agenda I think there's a question by Josh but I don't quite understand it uh like Josh uh Josh's last uh question do you maybe want to rephrase it Josh yeah sorry I was just confirming that we would have to do another migration if we shipped let's say Blake and then a year later decided to ship theidon ah yes cool just make sure that I understood that correctly there's no way to get like a similar complexity to the initial migration yeah I mean the idea wouldn't be to actually do that all this Blake three versus posidon 2 is a decision that we should make before actually

deploying binary trees to DEET y test I'm sorry got okay so the last item is a new website um from the status team that we wanted to share um I know you want to say something about it if not we can share the link yeah we could also share the link uh it's actually uh State less. FY or we also have uh okayo did it we also have uh we also have the WTF version if you if you prefer to go this route um and

yeah we we just want to expand this uh this uh page over time we're actively working on it in fact um but we we we got the feedback that people don't really understand why stateless why should we care about this so we wrote a first summary of um of that why why people care about stat ethereum it's meant to to expand we want to use more items from veral doino which is still running but hasn't okay hasn't seen a major update in a while it was updated but by small by small patches um and we

want to to expand this but if people keep asking you why or even just ask you once uh why do we care about stateless why is it important at least uh this is going to serve as as like a small rational for this which will expand over time um so yeah if you if you want to make comments on this please uh give us some uh some feedback knowing that there will be a ma like I said a major Rite so um it's always useful to to get early feedback so so that we can integrate it in the Rite um yeah nasio did you have anything else to

to add um no not ready oh and we also have a new Twitter but yeah I'm not logged in so I can't show it um maybe nessio if you're logged in on on your computer you can but um I uh we have um we have also a new Twitter account and our handle I will type it right now it's state less okay you just did it again thank you uh we have created an account to help with the advoc advocacy of of stateless so we also want to to keep uh pushing things so please give us a follow if you

haven't uh most of you should be followed already uh if we forgot uh let me know and uh yeah that's uh pretty much it uh that's going to be our main Communication channel for for the months come okay uh we have five minutes left I I know if anyone else want to share any other thoughts if not we can wrap it up um just want to say thank you nasio for running this uh this call and stepping

up good job yeah okay thank you this my first time moderating so I'm sorry for any confusion okay so we'll see next time thank you you by e