EOF Implementers Call #60

Transcript

good morning uh this is our good afternoon or good middle of the night wherever you're at this is UFM planter call number 60 on the 16th of October um posted the agenda in the chat and here's the agenda we'll go over testing updates client updates um compiler updates U which are actually spec updates for Osaka de one that we're going to discuss and then some other items um and then yeah we will uh if anybody has any other agenda items they wish to add um please add them to the chat and we will get to them at the end um so first uh because testing is

probably the most important phase we're in we're going to start with testing to make sure that um we get enough time to cover it um I don't see Mario I only see Dan catops uh from the testing team is there anything from the testing team we need to be aware of hi Dan hi everyone um yeah Mario's out of office this week he'll be back next week um I don't think there's I don't think there's much to be shared on our side um we've been pretty busy with uh Petra DEET 4 um I mean the I saw that you've got a PR open that's been approved Dan I can merge that right now if you like Okay um

the stack validation in call F and then we saw um the introduce introduce e e rap Tool uh PR which I think is pretty pretty much good to be merged just uh gave a little bit of feedback on that today um but apart from that there's not really a lot for us to share this week okay yeah it's it's pretty uh busy going on with getting devet for you trying to get that launched by the end of the week so that's pretty time um couple of things that also went out there um there's new fixtures covering Osaka activation I think that's the next top thing clients need to start activating on on

Osaka we're not going to do like any eof um 7692 Flags we're just going to fully commit to Osaka because what we have today we could ship um even though we're going to be refining it over the next few deets it's in the state where if the call the ship went out we would ship what we have because it's it's the Improvement we need and we're just fine tuning things that are nice to have not mus hav at this point um that's that's my perspective on it um so we're going to just start shipping in Osaka devet zero um the goal um that I heard on the testing call is they wanted to do that about two weeks so about a week after um devet for stabilizes so we Al also need to rebase our um existing eof code on to

the Osaka Target which shouldn't be too much but I've been surprised before um let's see I saw fix so fixtures are published um what else did I have on here yeah um yeah so oaka devet zero is going to um be where we would have been at prag four if we didn't decide to split Prague um any other testing from anyone on the call okay uh I had

a I was resolving merge conflict with UF and our master um and it highlighted one I had a conflict with 7702 um and I highlighted an area that we might need to put a bit more testing into which is uh delegations and EOS so that was something that Mario added just before the split happened um and I think uh the new fixtures that's why he also wanted to include the Prague branch is because I think there's some tests there that test eof and um 7702 with regard to their to the the delegation that goes on there so so I

think there's test coverage it's very fresh um so I'm sure we're going to need more test coverage there as we go over it um but that's you know the fixtures included both Prague and Osaka because I saw he put that in the um um the G the git actions task that runs it so yeah that's a good that's a good Discovery is that there's definitely some interaction there um clients and compilers um Charles has already said he has nothing from um Viper and I don't see anyone from uh solidity on so we'll just go

over clients um Ben do you have any other news from nethermind um we're all up to date as of uh what is it 11 Z or 111 um I haven't done the a second move yeah okay and have you updated the um the Rus Matrix I no I haven't okay um let's see uh dragon anything from Revan um nothing much um I need to propagate Osaka hard Fork basically make

a release small small change yep okay um let's see gu's not gu couldn't make call um evm one no updates from us we still have to move have to aaka um ethereum

JS nobody Basu we have Osaka um published in Maine and uh maybe I should have mentioned this in the testing um the call F changes um came as part of my work trying to get the fuzzing together so I was doing a bunch of comparisons of Stack traces of execution and uh there was a case um there's there's a couple of rules in call F and jump F where you need to check the available height and uh break in a couple of places basally wasn't doing that and the tests we had were failing um because you still blew up the stack in the next uh call so those two tests that were just that um

as ceratops mentioned um per the type section they'll bust the stack but per the actual execution they will not bust the stack and that's one of the things that we found um checking traces so that's why uh checking at all levels is important one of the important things we get from differential fuzzing are there any clients on the call that I missed okay um so that's the case um we'll move on

to spec updates whoops what did I do um so as far as you we should have this discussion first um as far as spec updates go since we're ship shipping numbered T Dev Nets now we really need to Target which specs are going to go in which devet and at the state we're at I mean realistically um Osaka is not going to ship until at least the third quarter and that would be ambitious to ship in the third quarter things would have to go really well with Prague as well as Osaka um so there's going to be multiple

Dev Nets um but I would like each Dev nut to be in a situation where if we needed to ship it we could um so if there's there's critical things that need to be fixed we should get them in as soon as possible and as far as changing the um Quality of Life Changes I think those are fair game up until a certain point and another thing that's going to start um happening is people are going to want to have tools developed and stabilized so at some point we're probably going to need to close the door on quality of life changes too um just to make sure that that tooling um will start showing up and um we will will be correct and accurate

um so um knowing that I would say that the door for Quality life is open right now um so the spec changes we have discussing are a couple of um ones that have been around for a while and um a few things that we need to um uh possibly fix and possibly not change um the first one is e721 compati with the XT code the next is the EXT call return codes there's a new thread starting on eof create hashing that we're still trying to get um the final details and wrap our heads around um yeah and those are for the specs there's some nonspec things we'll get to after we go through specs um so first on ERC 721 compatibility um does anyone want to

um give their current opinion what the current status is so it seems that we go ahead yeah thank you um so we had discussed about has code and uh just enabling EXT code or a few subsets of it um my current thinking is that we should go the route of enabling the EXT code op Cod um possibly in some some limited form but maybe not and uh basically my rationale is just to

to avoid adding complexity um and I I brought this up recently in in in Discord where if we're thinking that eventually Legacy contracts will have to migrate eventually these up codes will come so we might just we might as well just add them now okay just a loose a friend okay um one thing that um Marius

did add is he's um he is opposed to it um he doesn't want to which is interesting for for Marys to have this position on it he's never been a strong advocate of vof but he does believe that it would compromise the spec to ad has code do you know what he means by compromise the spec um he if we're going to commit to um my interpretation of what he's talking about you know let him clear clarify his words if I'm not representing it well but um the code introspection um should be as absolute as possible um so allowing we never have allowed any other codes to directly um Divine the types of the code it's all

been secondhand through things like code size and if for taking away code size we should not add new ways to detect whether it's EA and I think the strongest part of his argument um is he says that the 7702 delegation is going to significantly uh change the landscape of what accounts are and that EA accounts are not going to become the norm um the delegated accounts and smart wallets are going to become the norm and in some of the AA road maps that I've seen um there is a step where all eoa accounts will be migrated to an equivalent smart contract account that would behave exactly like um the existing eoa accounts um they would just be done through smart contract and that

would be one of the final steps of some of the E of the um account abstraction road maps that I've seen published so one of the things on the horizon is they do actually want to get rid of the notion of an EA and have everything run through as smart contract accounts well yeah unfortunately he's not here to discuss but I don't see how that's I mean the whole point was just EIP ERC 721 um just requires this right mhm and I and I would love to see the point about Legacy

migration being a part of the conversation do do you guys think that's not relevant anyone from um client team want to raise a response to that or anyone from ipsilon I mean it's a it's a indeterminate future thing that we shouldn't rely on or expect um but related to not having them it's also a problem with

um not being able to delegate call to uh um Legacy accounts uh Legacy C because you can't determine if it's paid um unless unless you do introspection through trying to delegate call to it first see whether it fails yeah and also um I'm not sure that you can get EXT code op codes via Legacy contracts because don't they um return

some magic if they're called on eof contracts so if they target eof contracts um it returns as if it is the byes um EF z00 but for the purpose of um 721 um that's the answer it wants it wants to know that it's not an eoa so it actually works for 721 and for um for the case of proxy contracts that's also what actually wants to know is that it either is I mean if it's EF z00 it can't be faked so it gets the answer if it gets that hash code the yes indeed this is um the eoa um it's not EA it's an eof account and we can delegate to it so the

the Legacy op codes jumping out to them will still allowed to answer these two questions I mean I think the sanest thing is actually to mirror the um Legacy Behavior so if you um actually yeah I'm not sure yeah yeah to be clear when we talk about enabling the EXT code op codes it would be with that behavior so you wouldn't be able to actually look at the code of an eof contract um you would get the same result that you get from a legacy one which is opaque yeah that kind of makes

sense I think the only other alternative is for it to be solved at the application Level so for there to be a standard where like one thing that contracts can do that well two things that contracts can do that EA can never do is um revert and return data and so um if you have like a special method like his contract for example um in this in the standards can you elaborate on that about revert and return data I missed that uh one thing that EAS can never do is revert and return

data so right now you like um I forget exactly how you do it in ERC 721 but you ask for like the on receive hook or something um so if another thing was added to the spec like is contract that all ERC 721s like going forward have to implement and like all erc's I mean it's similar to the erc1 165 solution that was discussed on previous calls right so so what I just read this spe this morning again to make sure I had it straight the uh safe send it'll send the contract and then it'll try and

do the call um or it'll do the size check if it's a size check and determines EA and safe send it's done sending because it knows it's in OA if it doesn't get the size check it says as contract it tries to do the call back unless the call back returns the value I accept it it reverts so you have to receive the the nft so you can't accidentally um store the nft in a contract that doesn't isn't aware that it's being sent in nft um so that's the tricky part is that um an EA will never be able to return that positive confirmation so the contract needs either positively confirm it's an eoa or positively confirm that it's received it and the problem with

everything except for the um uh to check with uh the EXT code size is you can make any contract simply through the calling interface andersona Thea and there's no way to distinguish it within just a call um so I was thinking through this is like could we just do like the 165 approaches to see if it's got a registered receiver and if it doesn't if it's not 165 registered and we assume it's an EA which actually defeats the whole thing because what if it doesn't Implement 165 and it doesn't implement the receiver call um and it impersonates an EA and returns nothing on all calls the default Handler just returns nothing um I mean that is you know you could argue that that contract um has

deliberately um put itself in a bad place um but that's creating space where the contract could misbehave um so yeah um what is ion's opinion on on some of this um I think that's a opinion we haven't heard much from them yet I personally mostly agree with Mario's stake I think and that it should be solved probably on on the standards level not in the evm so for me ideally we don't introduce neither of these and has code is a bit better than x code size for me if we

really need this okay I I really I really hate to be on the other side of this but I just I just don't see the rationale for this um like I was looking back at the balic post where I think he introduced the um the idea of removing code introspection and there's a very clear motivation there which is we want to be able to in future versions do translations of APM code to deprecate up codes or change Behavior without breaking backwards compatibility so you need to remove say exd code copy so that you don't inadvertently like indirectly

introduce breaking codes uh breaking changes that's a very clear motivation and by making eof contracts opaque so that you can never do EXT code copy it seems to be already addressed um now the current status of eof where you're not even able to invoke EXT code copy I don't get where that comes from and it's it it really causes issues at the application Level and I don't see a good rationale or motivation so when these decisions were were initially made on the whole perspective on what Banning code introspection meant

was that none of the code anything that hits memory will never become code and nothing that's code will ever enter into memory um so it's it's it's the bidirectional thing um and that's that's kind of needed for ZK um at least for the for the memory to code because compiling a new thing on the fly in ZK is kind of difficult and it backs them into requiring arithmetization so that's where the the

premise of banning exe code and then similarly um the reason why we banned EXT code from introspecting existing eof code is the situation where you call into Legacy have Legacy do the exd code copy from the eof then come back and return it um so that's why the decision there was made to have all e code um look like the byes EF z00 to Legacy so that the eof code um then would not have to be preserved um if you cross over into Legacy uh so that in in in situations like that the Legacy code is um yeah the Legacy code can't go into you can't use Legacy as an escape hatch to um do this code

introspection um which it kind of touches on a little discussion later on why we still need to ban um ex delegate call um because if you delegate call into Legacy code anything that's banned in eof is then allowed in Legacy code can then be done in eof um the first and strongest argument for that was self-destruct and that because we didn't want have self-destruct in eof um but we still have self-destruct we just have it within a transaction um so there's no self-destruct for pre-existing contracts but contracts made within um a transaction can still be done we don't want to expose that to to um eof so that's why the ban needs to still be in place because self-destruct was not completely removed there are still things that can be done in Legacy um that were also very committed to keeping

out of e um I think the self-destruct stand is a bit stronger very strong compared to the um code introspection um but yeah it's it's the code introspection there there's a lot of for from what I'm I'm hearing today um we're not going to come to decision this today and I'm going to go ahead and time box it because we've been on it for about 10 15 minutes without any any new positions on it um I don't I don't have any objections to to Banning delegate um just on the code introspection is the equivalent of just checking an account balance is not um it's not it's not a

particularly detailed introspection you're just checking like code hash or um if you get what I mean right it could be an attribute stored with you count information well I mean you you're you're either because we're already checking the code to see whether it's eof when we're doing all sorts of things um you know checking checking the first bites um and for code hash I mean that that is just as that's already on the account that's just as much work as you know what's The Ether balance of this account they're they're not like they're

not like deep introspections um you still don't you still you're still meeting all the conditions that you you highlighted before is is what I'm saying okay because it's you know opaque um it's not a complex thing to do we're already doing eof checks on on the actual code and the argument would apply to code EXT code copy as well right yeah and you just go hey here's your two bytes or whatever it is right so does although that has the downside of um people might then if it works on

if code copy works on Legacy code then people will be deploying massive data contracts in Legacy code then using Code copy and so that might not be good I don't know or it might be good um answer oh sorry Charles goad no go ahead I was just I just wanted to give Dan a quick answer that that the rationale about um ZK circuits I think that's that's great like I I want to see

the choice motivated by that kind of thing um and I'm not fully clear to me how all that fits but it seems like it my proposal doesn't really um pose any issues to uh ZK circuits either but I I'll have to read more about it and think about it more okay so um um this is probably a good

time to take a side go ahead want to point out that enabling um has code doesn't necessarily preclude from like doing the full AA thing like in the future all accounts just return has code equals true uh but I haven't been following the details of the AA road map to be honest okay see if I'm getting my headings correct here okay looks like it okay um so this is not a decision

we're probably going to be able to make before January anyway um because we've got Devcon coming up we got um pector oh soak dev. zero and imagine after that we're all going to be writing um we're all going to be writing our talks and uh with dev. zero I think it' be a good time to demo some of these solutions that may or may not work by keeping it out um demonstrating either that they're feasible if there's options we should whoever wants to say that we don't need it because it's feasible that would be a great time to show it the feasibility of it um or to show the difficulty of it um but also it's a great opportunity to um yeah if there's it's a great playground to figure out if we really have what we need and to really show where the quality of life

problems are good if we don't Implement some of these how they're going to negatively impact us um so yeah so so devet one um we're going to probably not close any of the spec items until January on this so I don't think we're going to get anything on this list resolved today um next on list the XT call return codes so this was something um while I was working with um the GU team fixing some of the final bugs um that was brought up in one of their code reviews is that the return codes um seem to be somewhat

inconsistent and that it might be um a reflection of how G reflects some of the errors within their code and they also um it might be you know that we're not getting some of the intent of the return codes um so one of the things that I think they brought up that might be worth noting um was right now we have um three levels of return zero success one is if there's rever or some sort of other error in the call process and then two if there's some other halts and those halts would be like out of gas static violation um some other evm level exception um where the spec says You must you know

then then then halt the frame um there's really no good way to distinguish between a call was successful and reverted and a call failed in the process of making the call per the um 70 is it 7069 or 7260 or 7560 which was the Call 7069 7 69 so the one proposal I have that I'd like people to to to mull over um is to expand the call codes to add one more category um zero success one is reserved only for a revert operation called in the frame above it if the frame above it terminated with revert op code and

returns run one and no other return for that number two is reserved for if there's an error in the call sequence that's where we do things like make sure there's enough money uh make sure there's enough stack make sure there's enough gas um as far as gas reservations and all the other errors are specified 7069 in the uh 12ep process wherever many steps there are right now to make a call um so those are like the light failures so those would get their own category so we could say that there was an error in you know you didn't provide enough gas you didn't provide enough money um you know some there's not enough stack there's something in the in the call process that failed and then three we reserve it for all other errors where the call succeeded went into the next one

and uh failed um for some other reasons uh static uh accessing uh stored memory in a static call is an example of that um infanio asks are there use cases uh where this information is uh useful um it's a good question and ipsilon what was the use case that was motivating this to split out return codes other than um simple utility I think the the main motivation was um this return code one which is like contract wants to know if if the revert was used on the other side so I think at

least I think we should confirm that again but uh that like feedback from solidity was that they are much more interested in this like programming error in coded in some other codee right in some other contract so so they were yeah they wanted to know if there was revert or there was something else so so mostly this two categories but later in the process of implementing this and um refining the spec we noticed that um I don't remember exactly but there was some issue with this that this revert instruction invocation was combined with some other errors I

think the slight errors somehow and and there was some reason for it I think there was some information leak that maybe we didn't want to I I don't recall exactly but I think that was kind of the the critical point when we kind of like combined two set yeah so I I like what you described this as these three different categories and uh and I think initially we had we had like two categories combined and and now we combined it in in a different way and yeah so that's more less the the background although I think some of

these bits should be confirmed again I I would assume but I like what you what you described that I think splitting that in more categories kind of solves it okay all right any other comments yeah so so I think that's that uh like this this error code was revealing some gas information and and going into this like full no gas introspection path I think that was the

reason why we change some of the uh errors for for the SL errors which don't consume all gas so we don't reveal this information um yeah I think we'll need to take a look on this part as well it's not always let's not forget that

there's always the Legacy contract call to a gas contract to get to your current gas level since as we pass everything in so there's still ways to uh to defeat the gas interest inection yeah and also um call stack introspection which interestingly we don't have a up code to say what is your stack yeah I think that was one of the issues brought up on a previous call if I'm I'm like dredging through my memory but um

basically you can tell if you're at the begin at the end of the call stack not like necessarily in the middle it's not very detailed but you can tell you at the end based on some of the return codes at least as it was drafted at one point um with the 6364 rule is it possible to get to the end of the call stack at current gas levels I'm not sure that it is because I was remember reading some of the analysis Peter I think it's like B billions of of God's order of magnitude more or less as far as I Rec okay and so not not main

numbers as of today I'm Dan do you know if the like the error condition that you want to break out into a new status code is that exactly the same as the light failures that were apparently the reason to merge them or is it something different so it would be the light failures that we move into the new status code separating it from reverts um so right now everything that's a user revert or everything that's an error in the process of doing a call stack uh failure would go into type one

I'm seeing as the rationale in the AP is that it seems the the difference is whether the failure preserves gas or consumes SO gas yeah that's not true in the implementation um I think there's errors that that that that was one yeah I think there are ways where you can have that violated between one and two where all gas was consumed and all wasn't I mean that's the other I think

that's the other option is to stick with that original rationale and change things as necessary to get back to that level um okay all right I think we spent enough time on this that gives us the info we need um e create hashing is that something we want to talk about or we want to continue talking about it on Discord just curious if there's any strong preference

currently for UF create hashing yes for a solution or change or status quo what removes unnecessary hashing is I think what's preferable and I think what prompted this is um having to double Hash a subc container to get the new address U so performance-wise reduce the number of hash calls this also ZK hates could check cashing um they can't say enough bad things about it um so the more hashes we remove the happier they'll be um yeah I think we we want to remove the

hashing at least uh try a solution that is good enough and uh yeah I think we discussed this offline um and there's some issues with the the current design without hashing and I I have some preference preferable solution but I I I don't think we need to talk about it today okay um I still like trying to WRA my head around this I think there's a solution I think if we specify that we use the address of the contract um in eof nested creates that I think that gives us all of this

safety we need um but I think we need to work it through completely yeah I think we kind of have different goals so that's the kind of my impression from the discussion we had that like my goal is to be able to kind of prove or like predict the address on like physical code that will be used to to create it um and I think it also gives you a collision free somehow addresses so yeah but uh it seems to me that we need to kind of

instead of just contain subc container index we need a pu because that they can nested and I'm not sure this is this this complexity would be accepted but uh yeah I think we need a bit more time maybe we need to prepare it for the next go or something okay um so that's it for the spec um top item for others tracing and the one thing I want to pitch um is PC equals um zero is start of container

so when looking through this and while working through some of the um the fuzzing efforts I'm trying to get started up um at the very least all the um we need to have PC that is zero relative to some fixed point in the container and not to every section's beginning um because it's going to be uh more useful uh it's going to be it's going to provide better signal within um go evm lab if we have the PC relative you know consistent across um some Z pointed container um and my preference would be the 0 point of the zero byte of the container of the EF header and my reason for that preference is it's going to help us out

when it comes to veral because the veral we need to Mark which code has been visited um in addition to taking in the entire header probably um we may not need to take the entire header in that's something um we could consider um but in in cases where we would need to split up by section we would have call fs and jump FS to signify that we're switching sections so I think we'd have that info in the trace um but just as far as as you know getting all the clients I think all the clients except for GU we're using PC that is container relative rather than section relative and I've got a patch out to get to move it to container relative PC instead of section relative PC so that's my big ask is can we you know if if there's support for it

being uh relative to a spot container if we could move it to the Zero part of the container so a lot of the traces would start like PC equals 19 or pcal 23 or whatever so the entry point would never be PC equals zero what are people's opinions on this am I asking for too much am I crazy should I move back to code section zero index zero did we um like in the previous design did we have did the PC with resets to zero on every new section yes so my first my initial pitch of the tracing spec was PC equals z for

each section um and it's possible to do that in in the code because you can look at your your offset in your section when you do the trace instruction I think every single client could write that Trace code um but the reason we went to container relative indexing was for optimization and speed do you still want to include section number uh we still want to include section number yeah but I think that's going to be an optional field um go evm lab doesn't have allowance for that I could easily write code to add it um that's something we could easily add to check yeah so like from my perspective

um um what we currently are doing is that we kind of start from pc0 but uh yeah evm considers like all code sections as like kind of single section because if you think about it they're actually adjacent so they are and the kind of boundaries are defined outside there's nothing really in the in this code that defines like we're crossing different sections and if you just start interpreter based on the previous validation that doesn't matter um so like for us it's a bit

easier to to just have like Global PC counter uh it's more naturally to start with zero but I think remembering the offset somewhere I think it's it's not a big deal so like internally it it starts with like it uses zero as a as as the internal representation of the current position but I like it's not even an a number I think it's a pointer so um yeah so I I think the compute the PC I need to subtract it anyway so I can subtract it for something that is like yeah so that's that's fine so I think we

can go we can do both my prefer would be to have like Global counter it means either started with zero and not resetting to zero on every section um and to implement the section IDE I think I will just do it for tracing just I don't know look it up in the header if that's needed but it's likely we will will keep it if it's not needed okay um Dragon what is re's thoughts on this um implementation wise either way we can make it work

yeah okay I don't have it sounds it first at first it sounds very strange to be honest but [Music] maybe maybe that's the way to go to start PC from start of the container but I'm not TR to be honest okay Ben what's NE mind's view on this um fine it makes sense verle um yeah any objection is be some change that's fine okay okay and it seems strange at first but I

think one of the things that I noticed um is when you look at a trace and you see your first entry is pc19 you're going to break open the code and you're going to go to the 19th bite of the file and you're actually going to have it whereas if it's PC zero you have to parse the entire container um to figure out where the first bite is Peter the counterargument could be that PC starting from uh like 19 like you said allows it to represent something that's not possible so smaller than 19 or whatever like more more of a principle approach but maybe that's an argument also I mean uh how do best put

it starting from this zero being the start of the code section makes it impossible to represent impossible states of the machine maybe like that ah I cannot I cannot AFF uh I mean you know what I mean like yeah yeah you could never run zero but I mean if you if you think of normal solidity contracts they they have the a big chunk of um convert this method hash into a jump so I

mean people should be used to the the the start of the code not being anything either okay but with pc0 the the flip side is you know that you switched well you don't know when you switch into a new Call F but you know you switched into a new call um apart from the the the depth increasing and it's more more consistent with Legacy in a way I guess okay if any toing is concerned you

they they would have easier life but but I'm not you know this is not a strong argument of course so right now evm one has pc0 at section zero yes yeah and reset the PC across section calls no okay I think we don't okay how about um re um sorry can you repeat that um pc0 um is at section Z by zero right um current code I think currently we don't even have support for Tracy for that yeah I need to check

that I think it's like zero it's zero from the code section I think that's the case so code section one pc0 is by zero in code section one yeah okay um how about NE mind do you know what your tracing is doing it' be the it' be the same the first bite of code how about section one what's uh the first bite of section one is that going to be a zero where or is that going to be offset it's going to be zero as well okay but um code not machine code so there's like a preamble isn't there okay

so I I think you're saying you'd want it to start at the start of the Preamble the um yeah started the Preamble and it would reset across section boundaries I think the big thing that I want is that it doesn't reset across section boundaries and whether we zero it's code section zero or whether we zero at the Preamble um is where the open question is but as far as fuzz testing um we really will need to have uh continuous numbering not resetting numbering okay looks like we are at time

is there anything anybody wants to check anything wants to bring up on this call I think there were still a few items that we didn't discuss but we can discuss that in two weeks data copy and data size is a big one all right hearing none um and given that we're up against time I'm going to thank everyone for their time thank you for calling in and implementing and participating uh see you everyone in two weeks