EOF Implementers Call #7

Transcript

hey good morning everybody um thanks for joining us for the UFL owners call number seven this is the first call that we've had in a few weeks we spent some time a few of us in person at the interoper event in Austria and uh yeah did some work on eof had some discussions about how eof fits into some of the future roadmap ideas and so I think it's going to be a good time to talk about what happened um you know at that event and then what people have been up to for the past uh two weeks or so since we've been back so I guess to get started let's just go over what the clients have been up to at

the interruptions the interrupt yeah I know do you want to start with Basu sure um so we had basically gotten up to implementing what's been called ufp1 um and we were engaged in the reference you know looking into starting moving some of the reference tests over we validated some of the reference tests none of them had filled properly because it's still a very uh fluid spec so that's not surprising so I did differential testing against I think the other most complete implementation was get and off of like kinds clients fork and I did differential testing there came up identical so we were ready to ship uh V1 but you know because it brings us we're going to discuss later on I don't think it's ready to ship in

Shanghai there's at least two issues that need to be resolved and some more existential issues that need to be resolved before we can comfortably go ahead with it um uh unrelated to eof um I've got our evm tool implementing I'm working on having a different t89 and b11r so it can become a full partner in the execution test clients uh execution spec tests um that's still underway it's not complete there's still rough corners and you know not even guthren's gifts right now because they're changing some of the M Fields so it's you know apart from the course on there right now that's awesome if you run into any specific problems while you're implementing those feel free to tag me in testing the testing Channel or something or if there's something wrong

with Geth implementing those interfaces yeah I'm happy to update them yeah right now the issue is around um brief base fee and there's no current base fee in some of the tests that come out and I just need to read in what the SS is expecting the client to do it when that happens and then just making basically do that and I think Jeff is in the same boat there they fail the same test okay interesting uh okay cool thanks for that update um do we have another mind here or Aragon does somebody want to give an update on

evm1 nothing uh I can get a give an update for guests then and update us there's not too much of an update we you know we spend a fair bit of time talking about eof spec uf2 spec in Austria and since returning I haven't spent much time at all uh it you know working on a deal of implementation I think there's some outstanding small issues and some things that would need to be updated but I've just been focused on a couple of different things and so that's been on the back burner still waiting for things to settle a little

bit to figure out what we're exactly targeting so we can get back to the place where we're doing differential testing a much against a bunch of clients so yeah that's pretty much where the Geth client is any other updates on I think that there's a bit of an update on evm1 and erotic and Anthony can speak more to that um but Andre has been working on the create three implementation which is um this basically this new um Contra creation model

um or getting rid of them product observability and we have shared these documents um create tree is one of the instructions between contract is another one and Andre has been working on implementing this in evm1 um and the intention was that implementing it gonna give us some um we're gonna find some problems with the design and I mean so far it seems to be working um it did help us Identify some edge cases which we need to describe separately to that um just as of yesterday uh t8n transition support has been merged into evm1 which means it can be

used to fill tests and so we will be able to once we have this create three stuff implemented we will be able to build test videos and that should really accelerate the you know the way we work and test any of these changes across the clients are you guys looking at implementing b11r at all um is that as a block Builder right right this one is is required to be used with the execution spec test so I think T8 in

the only requirement you know it's the only requirement if you want to be used with retest ease but to be used on the the python spec tests it does require having b11r as well yeah I think so far we haven't discussed that um so my concern with b11r is it's very tied into the ethereum uh chain format and things like the current existing Patricia tree um would it be possible to have the python client use one client for t8m and another client for b11r would that set hybrid to discussed as an option yeah I mean we we could have the we

could add the ability to the python spec uh python testing library to take two different binaries but I wasn't sure what you meant by the b11r tool is tightly coupled with like the Patricia try because it should really just be like Computing the ROP of a block and Computing the hash over that yeah maybe I'm thinking of t811 so many numbers in these yeah but the thought that's crossing my mind is you know with this utility of this for likely or two clients they're doing novel things like switching their um switching their their hash tree um to like the sparse Markle tree is

there a way to make these tests useful um for the layer twos they're pushing evm compatibility so we can run a test on and say no you're not here's your errors or yes they pass the tests here have a cookie yeah that was a good question we should think more about that for sure I do think that you know a lot of the ways these things are structured it's something that we can support with relative ease but yeah it's just getting to the point where we might be boiling the ocean to support everything and right now we want to make sure that we are supporting L1 Focus I mean a girl Layer Two off of it yeah yeah we should think about how to better support layers who's uh sorry

anyways we can talk more about this on testing the last thing that I wanted to say on this is I think that supporting b11r would be great and I think that you know writing the tests in the python formats is is pretty nice because it's really simple to change all the tests where I think that with the retest ease format it's a little bit more difficult to go back and change tests as the spec changes and we could talk about that more in a few minutes is are there any more updates on clients okay any updates from compiler folks um I think the update I have uh from

Danielle I mean this is the second hand update Daniel said that the basically implemented everything of V1 with the exception of our jump V and yeah I think and they also worked on some of the optimization steps because they're the easy way to enable UF support initially was just to disable the optimizer just to get everything else done um but they got as far as re-enabling the optimizer and actually extending it yeah the the result is that both code size and gas usage-wise there's stinga savings actually

I think they haven't done anything yet this year with the exception of Daniel participating in in Edelweiss and helping in the create discussions got it okay yeah great spec updates I know there's a lot of stuff discussed in Italy's du Alex and Pavel want to try and give an overview about the things that we discussed with respect to elf one and these ideas about eof2 I shared a document uh

just at the time of the call so nobody had the opportunity to read it um but that gives a and summary and like an overview of what we could do um but going beyond the EOS V1 but I think probably if you're on the call you are in the best position to summarize the status of eofv1 pack changes um because generally we uh we wanted to lock in what we had in December as ufv1 um and any further changes I mean major changes we would be doing under eosc 1.1 and 2.0 and the reason being is that uh we don't want to influence testing and

break testing um you know with eofv1 but I think there were some clarifications for V1 and maybe Pebble can talk about those yeah hi um um I think um the one was mostly missing this like one one thing about the create how how we handle invalid um invalid init code in case of create transaction create instruction so yeah this is like ongoing for longer but I try to like get a piano from many people uh on the charts and I think the we kind of

have we we have a solution that satisfies most of the people so we kind of went to the process of updating the implementation tracking tests and and so on and uh this is kind of like one Edge case that remains there uh which I think it's fine but it's uh requires some additional infrastructure in at least on the evm1 side and we didn't tried it yet uh how how complicated it makes the the implementation in the end maybe it will actually simplify it in many cases but we didn't try it um yeah so I think it's a bit mess but

it's always with the create and call instructions that everything you change it's like it's like series of 20 or more different tracks you need to do and depending where you put additional checks and how do you modify existing the security effects um the the semantics although this mostly like edge cases that will not frequently happen on on real Network um so this is the status and I think we'll go we will continue with that and maybe we'll try to evm1 this time as a like first implementation to fully conform with the test and spec um but also yeah so that's kind of this

is this is it and uh I I'm not really prepared for like the the 1.1 but mostly what we had what we wanted to do is to include some changes that we are already agreed to be included but we didn't just not uh disrupt the testing of existing spec I think there's like around five different changes including delegate call restriction um and some minor other things uh I don't have the list right now um however the the thing we we also discussed during this interrupt last month

what was the conclusion that we actually should really the the ability to create in create a contracts from UF mostly means we should disable create instructions so it's kind of it kind of makes the all this struggle to create semantic a bit wasted in the sense that we'll probably disable all of it but maybe with that will like be useful later on at some point so that's my comment about it

so you're saying by disabling create you're saying disabling create the original op codes not talking about the the new ideas with create like the transactions and yeah I didn't fully like check out this new create instruction then you create semantics if if we need to handle all the edge cases the similar way or maybe some of that cases will go away uh I'm not sure about that uh but yeah by disabling I think we kind of ended up on the on this position that uh if we want to deploy eof in two phases

and so we want this new fancy create semantics um then we need to kind of disable it for now and then introduce it later without need of modifying the El version so yeah more or less there will be only option to create eof contracts starting from a transaction so this is kind of like like I don't know partially functional system but I think it's like in my opinion is it's it's good enough to start with yeah makes sense

uh any questions from anybody on these ideas eof1 1.1 B2 [Music] so 1.1's not uh for its compatible extension of one right because we're removing features only one would ship one or one point one ship I think the idea yeah 1.1 is what would be the target for shipping but they're separated into two just because sort of one was already defined we have a lot of tests around it 1.1 would be uh you know just a change on top of that

so one point the eof1 is basically eof beta foreign so 1.0 it's it's what we currently have in the aps um and that's what we would be like implementations we're targeting and what the testing are done for and we didn't want to this this disturb this uh because like we assumed this ongoing implementations efforts and ongoing testing efforts um but if if like if you think it's it's not worth the continuing we can I think apply additional changes to that and

like kind of skip this milestone um I think the from my perspective like kind of buff options uh I'm fine I I was a bit happy about having some Milestones some like multiple teams could confirm they they they passed all the tests and this is what we had but I think like I'm I'm open to going yeah to selecting one of the dudes yeah because I don't think we have a good infrastructure to set a basic yet to ship both 1-0 and 1 1.

um without changing the major version number uh you know from like you know true forwards compatible where we just add new uh op codes and admin capabilities and increase the uh space that is valid contracts I think that's easier to handle inside of Basu but to have you know restrictions would require separate code bases right now so I I think 1.0 is valuable you write for testing but as far as shipping wants 1.1 solidifies I don't see base 2 continuing to support 1.0 so you know it would just mean that contracts that were compiled with those forbidden features would suddenly become invalid in hyperledger basic which I think is probably okay because all the contracts that don't use these forbidden features should just

transparently come in if you're not creating stuff if you're not using EXT copies uh the XT code series of operations and doing gas introspection it should just well no it won't work because we're changing the gas on the gas introspection so there's some things that might change it might be incompatible you couldn't do cross-contract calls which is kind of the big feature if we go with the uh in place change of call just dropping the gas field so I was kind of thinking that we don't necessarily want to to have both of these implemented at the same time it would be rather because as you say they're like many

different ways to enable like 1.1 and the the stainless way to enable it is with an actual version one right but some clients may be able to do it with uh like enabling a you know like especially IP feature whatever but I think that's maybe like unnecessary complications and how I was looking at this is more in terms of discussions um I think at this point um we need to spend time on the specification of what this 1.1 would be as opposed to jumping the gun and implementing it in every single client so I think we have

you know a number of weeks during a which teams can keep working on implementing V1 completely and passing the test because I think the tests are like mostly done so it's really just a matter of implementing uh in the clients um and parallel to that people who are like more involved in the specification of 1.1 um can work ahead and and finalize that and then you know in a few weeks time we can just jump to implementing all of this in the clients maybe it is a bad idea but that's how I felt about it I think that's fine

does this still put us on schedule for shipping in Cancun I think assuming we can nail down like this 1.1 spec you know early I mean I will put it after eat Denver because obviously that's gonna put a hit into this um people are going to be busy with the Denver but my target would be that the 1.1 spec should be pretty um clear by the end of the Denver um I think then we're like on a good track so the anticipation is still to try and

have this elf 1.1 uh specification used to propose the change for Cancun rather than trying to propose the full ufe2 or will we just kind of go into the conversation like here is this 1.1 spec does it make sense to do this on its own should we consider doing you know V2 all at once I have the and I shouldn't be the only one like giving feedback on this but my feeling is that uh V2 given the the sheer number of changes uh around

creation may put us into like a similar position as we were pushing High that it may be just um you know too big um given the time frame yeah um that being said I think we do have to be proactive for getting the transaction uh like the the requirements for the new transaction types because there's this ongoing discussion of the sscification of um um you know transaction hashes and the proposed the IP for that I think it has

this would have an effect on that so I don't think ufv2 SS would roll out in Cancun but I think we have to do as much as possible to prepare everything else to be compatible with the V2 that we want to have yeah that makes sense yeah I agree I think V2 is too much to get into Cancun but I think we'll know what the scope's going to be and what to feel for and so we could roll forward in Prague with the new features so yeah I I like this plan okay cool yeah let's just stay vigilant on these uh changes with the soc transactions try and make sure that what's happening there is amenable to

Future changes that we might need or want to make with eofv2 and also we just need to keep in mind uh and keep an eye on this proposal in general in the context of Cancun because I think this is going to be a relatively large change for the El and so I don't know if it's like necessarily competing with eof but if we think about El teams having a finite amount of resources for completing changes in their clients for Forks then you know this is obviously taking a piece of that so I think yeah it would pretty much be impossible to do the soz 4844 and eof in the same Fork

so V 1.1 is certainly our best bud in that situation I don't know if there's any specific things that we want to discuss on the spec I think the updates were really useful but we spent a lot of time discussing things in Austria is there anything that you would like to mention on the call or should we just talk about testing I know there's some outstanding PRS as well that need to be reviewed

um if we have the time I would propose to maybe go through this document I shared maybe spend like five minutes just on this 1.1 yeah let's do I think most of the the people on this call have been heavily involved but I do see a number of people who with those discussions in Austria but I do see a number of people who haven't so maybe it's better to be aligned on these uh ideas yeah let's do that we've got about 30 minutes left so should have time uh could you by any chance uh uh screen share it if you have it set up yeah give me one second

um yeah so on on the introduction uh it's just a summary of basically what we discussed already that we want to roll eof out into steps and the first step is the 1.1 where eof contracts can only be created through transactions and not through create instructions and then the V2 enables the contract creation and then I have three different sections here what the individual versions mean the under V1 I uh I meant that everything what we have today but I also included this delegate call restriction which has been a proposed I think a few

weeks ago a specific reason here yeah I I wasn't sure what's the the actual number okay but yeah all of that is included okay and then one point one is the the interesting one and here we only list like the changes which are different to V1 uh so it regarding creation yeah we just disallow the create and create two instructions in um in the euf container and that means

um that of course you cannot create any kind of accounts uh from an euf context but we still want to keep the external uh transactions to create eof accounts and here we discussed a number of ways how to actually accomplish this um and I think we ended up with like two options which seemed the most reasonable options uh the first one um and it's important to yeah maybe I should have actually listed creation and introspection um in the other order but what's important is um we not only disable create and create two uh but also X all the X instructions

uh xcode instructions and the code and so eof init code wouldn't be able to use code copy um to to get the runtime piece um and so to get around this problem uh and not introduce any more complexity uh one option would be that this uh init code euf um in V 1.1 would have this special behavior uh where the call data actually has access to what the code copy would have had access to and then it could context I'm not sure if that's clear but I can

uh I can go deeper on that I think that makes sense so basically creation today just in Legacy creation today in the init code call data is empty and code copy has all the code uh including any of the the uh Constructor arguments and because we disabled this code copy instruction there's no way to get that but the simple trick is that call data would have access access to that so that's like one option and the other

option is instead of having uh euf as init code we would actually allow Legacy byte code to create eof in a creation transaction and that means there's no special handling required but I think it kind of goes against uh you know the current specs where we decided that Legacy in the UF they cannot create each other and maybe for that single reason this might be too big of an exception and the special euf init code idea is the better direction to go I mean one I don't know I think one slightly

strange thing about the especially of context is like we're changing what the meaning of call data is in the context of just this eof creation contract and it is a bit of a you know a pretty large difference from how it operates whenever you're just doing a create transaction non-eof and because the query transactions the net code is very ephemeral I don't think it is as important I mean for you know in both cases but to me that makes it seem like deploying EOS from Legacy byte code comma create transaction would also be reasonably

um yeah I would say for the first part you said uh the special eof context it is a deviation from what we have today um but it is actually in line with how V2 would operate um because in V2 and that is a extremely long document this V2 design space um but I would suggest you know whoever has the time please give it a read it has a lot of interesting pieces but it is super long um the important part of that is we would have a create transaction where the code and data is separate and that means that the code piece would

have the init code and the data would be just call data and this code field in the external transaction would be a new addition we don't have that today um but in that Paradigm the call data copy in V2 would operate as it operates you know into special case so it's kind of forward compatible but it is a deviation from today so if the call data would copy the code that's associated with the transaction in the code list no the well in today the call data copy is the data field from the transaction

right and not but not in a create transaction I mean it's a special context it is right okay yeah in this special context yeah yeah and in V2 this still happening like that but in V2 you wouldn't send uh init code in the data field you would send in it but in a code field I see what you're saying okay so I think this special UF is forward compatible but yeah it may be confusing but doesn't that mean that the eof code ends up getting into memory and so then you do have introspection in this create yeah and I don't think we can avoid

introspection in the create transaction unless we go with V2 oh I see yeah that's that's the yeah that's the decision we made um it just doesn't seem to be possible to avoid this um if you want this intermediate step that makes sense um and then introspection I mean as mentioned X code and code instructions are not allowed and X code instructions have some special behavior I think what what is kind of clear based on the Edelweiss discussions that X could copy would just

work but it wouldn't copy anything um but regarding size and hash we had two options and we we're still not clear which is the better option um one option is they just keep operating as is uh today they give you the actual size and actual hash the caveat here is that we have to to mention that accounts may get updated and then these values change that being said I don't think accounts can ever be updated but technically they could um I mean that's the goal of the spending introspection another idea we discussed is eof accounts would just

operate as if they have the ef-00 as a code and then code sizing code hash uh return values based on ef00. um I think this is something we we really have to decide during this month um which is a better Direction and then the last piece is regarding gas um that was also like a link to discussion but I think we ended up with the most simplistic option that we just disallowed the gas op code and the call instructions get the gas value gas argument removed and we just pass all the gas

over to the the collie a piece of this discussion has been what happens with the stipend and the opinion is that since we we remove this option to to change it um we can adjust what happens with the stipend uh without any changes to UF so in v v 1.1 we likely would just leave everything this is but in V2 we could get rid of this type and then refine more things around gas um and then V2 we have a link to to this long document

but there have been three different discussions um we had afterwards which are not covered in the document there was like an interesting discussion regarding how to do uh contract Creation in general and one idea was that it would work based on uh called cloning and if you would have that then you likely would need a way to insert code into the state without doing any kind of creation you just take eof codes and you evaluate that it's valid and just place it as at an account nothing else happens

then you can clone that um I think this is an interesting discussion and probably we have to look into this um uh once we spend more time on the V2 idea um two important questions however because I think those really drive the discussions uh of the design whether we want to support data contracts and whether we want to support solidity immutables or if you don't then we kind of force people to use storage and the answer to to these two so far have been that we don't want data contracts and we want to support immutables and that is what drove the design describing this V2

design space document but if the answer to these are different then we have a different design space um yeah I think that's a long summary that makes sense that's awesome thanks a lot for going over all these ideas does anyone have any questions about this for Alex it's a lot of good stuff in here cool

any final spec related updates questions comments testing we talked to bit about testing in different contexts does anybody want to share some updates about what they've been up to some concerns some things that they would like to see we don't have the testing team on the

call do we don't have anyone from the testing team on the call but I know the Epsilon team has spent quite a bit of time writing some tests I know that I saw that Ori also has written quite a few tests I don't know if you guys have looked very closely into what he's been up to unlike Dennis the uh the assembly output that he's got of his UF containers it's just awesome to look out he's posted um so as as I've requested one of the calls we need to have a separate set of tests just to judge contract validation and uh coming up with the reference test there's a really nicely to those and if you look in the filler for it it was a really nice breakdown of of what they look like and I'm like tempted to see if

we could automate generation of assembly output like that it's uh it's truly a sight to behold um let's see we're gonna be in the where did he post the most recent copy of that uh was it in the testing Channel yeah I think I have this link is this what you're referring to uh that one diff uh yes I think so let me so there is you know work coming in the reference tests to get these in a formalized test which I think is really

good development am I able to share but what I was mentioning go down to the filler low diff um this is like the most awesome breakout of eof I've ever seen it's got the Legacy it's got the UF deployed code and it's very nicely lined up describes every line of what's going on this is practically a tutorial in how to build these things um so um I mean it's a lot of work just to get a bunch of tests and say pass fail but when you don't know what's going on to be able to look into these and see why is it failing what is it supposed to

look like in your code uh for future implementers this is just like I mean it's just this is stuff you could bring into a college classroom to teach stuff about it it's that awesome I'm curious what you guys think about this perspective I think this is like obviously super great in many ways but one concern I have with the way that this is formatted and probably generated is that it's not very easy to update whenever the spec changes like imagine that we changed you know I think we're sort of past the point maybe you know of changing the header format much but imagine we do change the header format you have to manually go in and update every single one of these

right that's why I wanted to know if there was a way we could write software to automatically generate this from standard output this would be an awesome thing to do right yeah and so I you know don't want to try to impose too many restrictions on how people are doing testing because it's important to get it done and at the end of the day if we hand write these things and it's a little bit of extra work it's a little bit extra work whatever do you think this is where the python execution spec tests shine you're able to derive functions that generate this type thing and it's much easier to change the implementation of one function that spits out a whole bunch of by code than it is to manually update

some byte code that was either generated with another tool outside of this format or something that it's like you know you're constructing sort of manually Epsilon do you guys have any thing to share about what you've been up to with I know you kind of said that you feel that testing is sort of coming to a completion at least for V1 so I'm not sure if Hugo has a working mic

um Hugo has been uh slowly focusing on on writing tests oh you cannot unmute them and I think right now Hugo is still doing uh the end of like 4750 test cases uh I think that's the the piece which gonna be close to completion probably in the the next week or two but I don't think we have started to write comprehensive tests for 54.50 um so that's definitely outstanding anything that we should be thinking

about and working on in the next few weeks obviously 5450 tests sounds like that's the next thing that Hugo is going to get up to any other considerations so it's actually one more yeah go ahead I can go after yeah just it's Wonder like how much uh other other teams are going to like do tests the implementation right now if if I think if like you assume that you will not spend a lot of time on it then we can drop some changes to the spec uh in this into this 1.1 Direction

I think uh if you need more time to actually test what is currently expect out um then we can move it further speaking from myself I guess I probably will not be working on update an elf implementation for maybe a month there's a lot of other things I need to work on so I would be happy if things were dropped into the spec and I just started targeting what the 1.1 changes are so I guess for that reason the T8 and

supporting evm1 seems to be a really good direction right because we can uh work on like this 1.1 without the need of goiteria yeah absolutely and I don't I think the only real barrier for 1.1 is going to be the changes to the color code for gas introspection I think all the other tests in there or just get rid of tests that use the user change the test to fail um so as far as you know just don't write tests for EXT and code copy stuff uh except for the v11 I don't think there will be too much Collision

between these two versions all right so there's actually one more spec point which was brought up by Danielle from solidity um is the solidity metadata which currently is at the very end of uh contracts and it is a seaboard encoded metadata where the training two bytes are the length of the preceding content and that's how to select sourceify can dissect contracts and see what the solid

metadata is and extract information out with you know the data section and the I think the Insight was that um it just seems to be the in in an ideal scenario we would have like multiple data sections or we um custom sections or whatnot where something on the application layer could be designated as State this is the metadata because this metadata stuff does some kind of encoding

uh like this length which really should be delegated in an ideal case to The Container format so I think what Daniel brought up is whether we should consider having multiple data sections we're having um specific metadata section or having custom sections in general so if we had a metadata section it wouldn't be introspected at runtime right it would be considered the same as the code yeah I think if it's specific uh it's a specific kind of section

then um and in the V2 what we said that only the data sections have the data copy of codes then any section outside of that won't be inspectable I would multiple data sessions work with the proposed op codes is another thing I think we need to consider or if we would just have one flat data space and require the contract to manage its own space based on that I would prefer a separate metadata section in keeping One Flat

data space for Simplicity but Simplicity is not always the best path forward yeah I think the the concern was that um at least with the ufv2 proposal we have um this auxiliary data which is basically the data you can send from init code to be appended to the data section and in that model uh solidity cannot really have the metadata at the variant anymore because

you would need to insert it from within like the Constructor so if we don't have a special section or anything then what um solidity will do they will place the metadata at the beginning of the data section which is fine but they they felt like that maybe maybe separation is good so it would be a separate unconstrained field of fixed length and it would just be opaque to do runtime and not accessible at runtime yeah I guess that's that's one option

another is as you said multiple data sections and it's still up to I think the multiple data sections is nice in one way but then it also complicates matters for the init code you know which data section is this auxiliary data being appended to um obviously the last one but maybe for this reason like this Bluetooth data sections it's just too complicated I'm not sure I think it's really just it would be nice to discuss these you know as we are right now I know that we are like uh finishing in two minutes um but then the next call I think it

would be the discussion points uh I would propose is like this metadata just agreeing on something which maybe we do what we do right now um and the V 1.1 questions I think we want to get answers to that on the next call next call is the week before East Denver well you know I can see yeah I think we were gonna do them every other week so that would be the 22nd

president okay I don't think I have it on the calendar yet but it would be the 22nd that would be yeah one one week before yeah so we could yeah I think oh it is on the calendar yeah yeah let's let's discuss it then and have people think about it but this before East Denver so we won't have any specs to push around so we can have an open discussion before we would expect to have any specs written which I think would probably be open up the design space so probably a good thing all right okay guys we're at the top of the hour

any last things to mention great thanks a lot it was good hearing the updates from Austria we'll talk to you guys again in about two weeks cool thanks see ya thank you bye-bye bye