EOF Implementers Call #9

Transcript

cool uh okay hello good morning everybody Welcome to the eof implementers call number nine um let's go ahead and get started with some client updates is anybody have anything to share since the last time we spoke um basically we're starting to test out its T8 and software um and getting some feedback from the testing team it runs against the execution client specs and just running around some of the undocumented Corners that we're encountering and what's expected like um if the reward's negative they don't want any block

reward touched or stuff like that so uh Alex anything to add from evm1 um I think you're very close to merge the Big E with PR which um basically implements everything matching what are in the eips and the test Suite um because previously these were like

several different PRS I and uh we also have I believe Andre is on the call so he could expand on it but I think we have a mostly finished implementation of the 2.0 stuff in regards to create um I I can give some updates later on on the call but we did a number of like uh back and forth in in terms of the design but I think you're Nearing um you know nearing down at one design um which is a bit different to what we discussed at either Vice okay yeah cool let's talk about that

some more in a minute American anything from another mine's end oh I think Island will cover that so I'm on got it uh we can't hear you I mean I foreign doesn't seem to be coming through for me I know that I'm an adjusted to the latest changes of here but I I don't know details to be honest so uh maybe we can go back when he fix audio yeah that that sounds good I'm in feel

free to interrupt this future audio working another reason to have Mike Dao okay it doesn't look like anyone from the compiler teams is here I don't know Alex if do you have any thing to share on that front if not we can talk about specs yeah I don't have anything but the solid team had the off-site thing in last week or this week which probably is more about planning and I expect you to get more feedback from them starting next week you know

when once they finish with offsite and all that okay sounds good uh also that made me think I remember talking to somebody at East Denver who is saying that arbitrim is planning to roll out an implementation of eof has anybody here talked to the arbitrim team at all is that eof or evm plus that they're talking about I'm not sure the person who let me know that this was happening worked on eof a little bit on Wrath so I think that it is uh it's eof not evm Plus

what about evm Max that is a separate thing okay you know with the evm plus they may have read our minds which has it either wise we were thinking about renaming UF to evm next or EDM Plus but we are too slow to make a decision and announce it on Twitter so I guess they they picked up the evm plus name instead and Craig what is evm plus it's nothing to do with evm as far as I know it's uh it's awesome hey I'm in uh is here Mike working now

I hope so can you hear me I hear you okay uh for never mind we implemented a draft for v1.1 and for jump F just to be ready and currently trying to see how virtual will be easily integrated into what we have right now and we kind of have some opinions when it comes to what has been discussed and what we try to implement hopefully we'll discuss them later this call oh thanks for the update anything else regarding clients or

compilers before we jump into spec updates um spec updates actually there's one thing Hugo from our team is working on changing the with your NPR um moving everything to Cancun um because with that he can't refill every single test to to Cancun because they're currently uh set to Shanghai so what the goal is that the the test Suite there's no changes to the

semantics um it's just changing the evm version from Shanghai to Cancun and for that yeah if you go exchanging to go with your MPR and that's I think I mean he's finished with that and he started to refill the test and he will push them um to the testing speed okay great uh let's move on to spec updates does anybody want to share how the spec has changed in the last couple weeks where we're at nobody else jumps I do have

a large number of updates regarding spec discussions excellent um let me just try to open this so we internally uh I think since the the last the US uh called two weeks ago since then we had two or three internal discussion holes in epsilon just to align at least ourselves in what we would like to propose regarding the changes and we took a look at the outstanding PRS and the eip's repo as well as made up our minds regarding the the flex

field which we just discussed in the last call um and I think we also kind of made up our minds in regards to the 1.1 changes and the 2.0 changes that's the summary let me just open up send you the links one sec sure so this is the the first

[Music] PR it's about changing how the table size in rgmv works and you have internally think that this is a good change and we would like to have it we've made some verification verifications to them to the pr I think it would be good to get like a final decision on testicle is anybody against emerging test change I think Dano and at least Deno commented on it so probably then it was there were what this changes I'm not sure what everyone else

Link in the comments yeah I think she did uh I thought we discussed something kind of like this I don't know if it was just specifically our jump V but it feels a little weird to have the table size be plus one the actual value encoded in the Opera operand so it depends if you look at the is this table size or is a Max index if it you know our jump one you could have an index of zero one our job two zero one or two that allows us to our jump 255.01 255.

so that's you know it does look a little bit like plus one but that's just the old zero one based indexing it's there's no clean way to allow what we need to do which is to allow uh 256 table with with fall through for a for an out of range number for a 256-bit without having this weirdness with it but it's not too weird do we have any other examples of using Max index because for things like push it's the max size so this would be a deviation from that format so the reason we are leaning

towards having this is um I mean exactly as you say the initial design was Guided by um you know spec simplification and really from the evm implementer side and the proposed change is done from the evm user side and it's clearly seems to be a really useful feature to be able to to have 256 locations because then you can have a very simple jump table and especially for having a jump table for implementing evm within the VM and I think we we feel like that the use case benefits over the the spec

you know Clarity in terms of you know is there any other op code following this scheme or not yeah I mean I think that that's the reasoning from our side okay yeah I think I agree with that reasoning the only other real option is to do weird things like our jump zero means 256. or do a two byte art jump I don't or a two two by our jump V so our jump fee size is zero is really size 256 that's we start getting weird and we don't want super large jump view tables which two bytes would enable and encourage people to try and use okay cool

what else you got for us yeah the the next one is um yeah this non's behavior for create and this is a more complex Topic in the sense that it would be nice to have uh I will on the call okay he's on the corner but also with the eof 1.1 and 2.0 changes this kind of becomes obsolete around the fringes so maybe I should explain what we think

should be the case for 1.1 and then we can Circle back to this because then there's more context yeah sounds good so with the the 1.1 um I mean I can share the document again we discussed this um I think the first call after a device and let me just share that link again there's just so many documents okay so this was the the roll admin

so basically uh with the UF 1.1 which is the other version we want to roll out that won't allow uh contract creation within us um so we are removing the create and create two instructions from UF code and the only way we enable creating UF contracts is through creation transactions um back when we shared this document there were like a number of different options had to accomplish that um and we arrived at a singular option which we think is the best and that option is that Legacy evm code in the

create transaction is allowed to create the UF code um however Legacy evm code cannot create UF code through create and create two instructions and I think currently there have been like multiple ways I don't remember what the 1.0 actually does do we then eof creation from Legacy or not but I think at some point we did want to Bennett um so the final proposal is that Legacy evm code cannot create eof contracts with Creator create 2. UF code cannot use Creator create two

um euf code cannot be used in a create transaction I mean it can but it cannot return anything so it's pretty much useless and that remains uh that the Legacy uh evm code in the create transaction is the one which creates eof contracts and at that point it can inspect the UF contracts because it uses the same old return mechanism um but if you like that any other option is just way too complicated for not many benefits and the only only way to

avoid any of that like intermediate complication is going straight to 2.0 yeah I'm not sure if any of this made like complete sense to you listening because I'm a bit tired and really better explained today um but maybe I will yeah can you tell me if the speed that is sets or should I try to write it down instead I'm only operating at about 45 so there's probably not on you if I'm struggling to follow so if if we allow Legacy code

as a result of its create a knit code to create eof2 then that means forever we would allow Legacy to create eof code so Legacy can always introspect would we still so it and in that in that create they can introspect into it right yeah but the only in a on a create transaction so during the create transaction before you set it up to the evm to deploy yes it is only the create transaction that the reason we want to burn existing Legacy code using the create doc code because then you can just have proxies right and right that definitely defeats any any kind of banning of introspection

so the only one is the the create transaction which it feels like it's a smaller surface area yeah that would just be a transaction with a band so if we did change the chain in the future to say you can't do that it would only affect transactions it would not affect deployed code would it or not it might affect deployed code no because you have a contract that's going to do a create I think we should include contracts doing create if it's reasonable no I mean that opens up the proxy case so then you can never get rid of it right well I mean get rid of so we have a legacy contract

and it does a legacy create ban it from deploying uh users create op code Banning that sequence from creating eof code so eof can only be created from a contract create transaction yeah I mean to be precise it's um you will have Legacy evm code as they need code in a create transaction and the result of that will be eof contract right so only they need code will be will be used yeah the Legacy will be used in other unit code so we don't have to design it for eof

we also thought that um maybe it's only temporary solution until we have the proper creation for UF but I don't know like I think it's debatable uh if we want to later remove also this this workaround or not I I don't see it's like super harmful actually uh because this init code will never end up and it's kind of like ephemeral in this way it only right yeah handles the creation transaction and then it disappears so right maybe I'll write my notes in there

but I just you know they're I want to make sure that there's no on if we can get away with it that there's no on-chain contract that depends on Legacy code creating eof code um that way it's easier to say well we just don't accept these transactions anymore and get the full eof isolated world for creation setup that we want so we can fully ban code introspection into eof yeah yeah exactly yeah we can we can decide to kind of also remove this this thing as well yeah because if we're ever wrong we can always add it later but pulling it out of a deployed contract is basically

impossible for the call but I didn't manage to I would like to add however that as we progress with the 2.0 there is a slight chance that maybe the 2.0 design will end up being simple enough that we could just go with it directly and we don't need the intermediate step right more we we can back towards some of those or you know split up the 2.0 um partially

um but until that is figured out I think this is the the option we are leaning towards um the the other major option we uh we're looking at is that it's a create transaction with eof in its code but then you need to modify some of the semantics and it's just too hairy it's it's it doesn't seem to work the the risk and and overhead having those like you know special semantics and then switching to 2.0 um right so in short I think what we're leaning towards is either we go with this option or we go 2.0 directly hi Lynn

uh my 2.0 directly mean that we don't do 1.1 we we just do full eof I we want v1.1 and V2 combined yeah wait a second okay I mean the the 2.0 could be also staged you know that I mean the design space is still open and and I think we could actually go without like a create transaction and only have like this deploy deployer contract and all that and you know this could be stage that only some of them is introduced in Cancun no no go ahead

I was gonna say that from our point of view we would prefer to do them all at once not uh separated like this since we found it pretty annoying and hairy as we said before to introduce that special context for certain op codes to behave like other opticals as it is mentioned in the document and we didn't like it to be honest and it will it felt like extra overhead and experimental stuff to keep in mind while implementing this stuff and yeah that's our stands on it we would prefer to do it all at once

yeah exactly what the you know the pieces you refer to as the one we ended up really disliking and and having Legacy unit codes is in a create transaction that's the only it seems to be in the only viable option unless we go to 2.0 directly what what good reasons do we have not to just go to 2.0 just do the whole thing at once it is just a sheer number of changes and we don't know the these size yet right because 2.0 isn't fully

um designed and and to to that end Epsilon is having an off-site at eat Porto next week and we hope to get more clarity on the 2.0 discussion um so I think it will be the next implementary call will be like a good time to um to see the complexity of 2.0 and where we could just go directly to 2.0 um so yeah I think that the next Implement record will be should be a good good time to decide um you know the direction we're going yeah I'm not sure I'm not wrong about

that but like 2.0 is mostly the create three instruction and like similar transaction so it's mostly like how to create eof contracts that's that's the only addition I'm aware of were we also looking into reworking call and getting rid of some of the gas rules and you will have this extra version forever in evm when we know that we want to change it in future it's like uh strange a bit that we already doing um two versions yeah was more of a soft

top version bump so you wouldn't need to actually bump the version yeah I kind of agree like this is like one one point of view but on the other hand uh we most we have like most of the things done for 1.1 and we can continue implementation and testing of this part why we kind of also think that 2.0 is is a bit more into design phase so yeah just just to be able to do some stuff in parallel that's I think that's my interpretation why it's going this way uh it also depends

how much time we actually have to for the first shipment Alex um yeah I would suggest maybe we move on you know with that respect discussions and then we Circle back to the 2.0 and the end of the quality of time lapse um but yeah I agree I mean 2.0 and done that's that's an exciting option Okay so with this um in in 2.0 with the create instruction one result of that is that we actually don't

care about the nons the account notes so it becomes like irrelevant and since we don't have uh the old create instruction which dumps the nons um we can fully ignore the nulls and now we can probably you know with this context we can talk about the the pr regarding the the nonce changes and maybe Pavel wants to discusses because it's his PR and I don't fully I don't really get uh you know what status we are in there have been a number of changes whether we bumped the loans whether we bump the nons maybe probably if you want to explain the pr

IDE yeah so um the spec how it was was kind of like unclear how it's supposed to work and the nouns is bumped when you when you do a creation of a contract using Create distractions and this is kind of um yeah you have to decide like what kind of failure make it to stick the nose Bob's the stick or like what kind of failure of the contract creation happens before the analysis bump but kind of this is always messy because this spec is kind of chain of different checks and different modifications but anyway the specification of the UF wasn't clear what when it's supposed to happen

and now we if you go to the create transaction the nouns is always bumped because this is kind of relevant how transactions work and we decided that in it like init code failure during create transaction is is not like doesn't make the transaction valid is kind of registered on the blockchain which means even if the init code fails the the nouns is already bumped and and like decision for the create instruction was to to to match this Behavior as well

in a sense that we bump the nouns for the for the sender of the create instruction and then we check if the init code validation is is good and if it's not the the north remains increased so that's was that's the clarification there is a kind of the other way of doing this and there was some back and forth between different implementations but not going into like historical historical uh aspects of that yeah this is more or less the clarification and I think on our side we are happy with that I mean I would be happy with whatever decision but we need to make one um

so this is this is what it the request does and this kind of mostly affects the current test we already have if we if we quickly just disable or like reject the create instruction in the year of code this this this this this issue kind of go away and we don't have to care about it so I think this is all also uh wow I don't know it's like this is always kind of alternative option how to solve it uh but I think I would like personally I would just like take make the the modification and we will make sure that evm implementation and GAP

implementation and this the generated tests are in sync with that and whatever we will remove some of the tests later I think it's it's not something we will be really sorry about anyone have an opinion okay I don't feel super strongly so I'm not sure yeah go ahead one thing

that crossed my mind with create three how do we deal with the situation of I don't care what it is give me new contract address that's what you get out of create which is you'll just do your your notes and your low in your current one um do we require them always to come up with a new with a new Hash a new solve for the hash relying them using stuff like the type stamp operation for the hash or is there a way to say just give me a different hash you could use and place on the hash right right I mean you could always use

different um you could use you could use an operation to give you random values I mean is that what we want to present as the best uh thing to get new because you also lose deterministic contracts you you don't have a deterministic address this is especially problematic for things like developer tools who want to do the same contract three times in a row and get the same three results in a row without having to provide the same three notices in a row I mean the same with that providing three different hashes so maybe we just change the process to them going away from notes I think has some some side effects on developer tools we're going to need a socialize and discuss and make sure they're okay with I guess is what I'm saying

I mean I like the idea of a fully deterministic address coming out but I think we need to handle a situation where the people creating it don't care what the salt is and they don't want to rely on you know what if they want to do multiples of the same they don't care what it is but they want repeatable which is kind of a paradox if you know what I mean but that's what you typically see in developer tools I mean do we just say you got to learn how to to code smarter or do we accommodate them somehow have you thought about this at all Pablo or Alex

I mean it just responds to then I'm trying to think about examples and family like how frequently people use even in testing or any of that and I I can't really I'm not sure I think the majority of contracts they actually don't create anything programmatically um you know because of like code size limits a lot of the like defy projects where you need to deploy a pool all of that is happening with um you know with external transactions unitop is only one exception with the factory contract and I think I think knows what they're doing

I'm more concerned about the college student well the college students are using cuff right so they they do crazy stuff anyway well maybe not costumes like boot camp people people who are like switching from from writing database applications to writing smart contracts you know the the people who aren't as as enfranchised and smart Contracting evm so it might be surprising for them I mean maybe we just need to establish patterns and communicate this better it's I don't think we need to resolve it today is but I think it's something we need to keep in mind of people who want to create contracts and don't care what the address is maybe we do just socialize using

pre-brand out as as the hash and just deal with the fact that in tests environments you might get different results and that they'll have to figure out how to reduce their entropy which is a problem they need to figure out anyway for a good repeatable system so I think there's like a distinction between like two different use cases one where the you know the programmer wants to do some of that creation and and maybe they don't know any better and the second is the testing in front of of Frameworks I would imagine that Foundry has so many cheat codes for everything I would be

surprised if there is no cheat code for finding the last Creator the contract address and maybe most of the testing actually works um you know with that in mind it's supposed to be returned as part of the receipt and a good tool can grab the receipt and get the address from that but the cheat code stuff isn't working because of receipts it it interacts directly with the uh with the VM yeah the create app code is supposed to return the address too so so I guess we don't need to fix it today

but I think it's just something we need to keep in mind as we finish out the spec yeah I would say the short answer is that we haven't looked into this um and then he helps would be appreciated you know looking more into to the question you asked so where is the work in Prior set progress for these are these kept on notes.etherium which I can't comment on because I'm not EF or are they PR as in GitHub um I would say the state of the artist the pr let me just push the link anything more on creatory so we're going

to implementation first route rather than the uh specification first route well we do have the specification from Edelweiss and there's no significant change to that um the I mean the the reason we're implementing it to you to find any edge cases and one each case we found was uh handling the data size limits um because you can push auxiliary data which is appended so how am I gonna have to dig through my telegram to find this link or is there some place we're keeping the note centralized foreign yeah I think like 99

of the links are put into the uf1 checklist okay I'll work off that one that's like the you know the master the master like link index but it's a monster it's just too big at this point and too many links maybe under the specification section in it um we can put like UF 1.1 and 2.0 it's a subheading and that could that could be a good way to to find these uh should we move on to other spec

yeah I have one last piece from my side um okay yeah actually with the the create three we did had one question um but yeah let's let's move on and then we can Circle back so the last piece is regarding the flags uh on the last Implement there's call we had a link to discussion whether we should have flags as a flex field in the type section or not and I think we were torn there seemed to have been you know some reason said it's maybe useful um but a lot of people argued that it isn't

um the two extra use cases beyond the non-returning function um uh which was discussed was the Purity level um which I think is still like a good idea but I don't think we're gonna have any time to properly investigate it and maybe making a decision based on um on this unconfirmed idea is is probably bad and so the only remaining reason uh was whether we should Mark in it code with this flag or not there there have been some reasons why this could be useful but as we went down some of these creatory um

discussions we realized that it wouldn't be sufficient to have the flag uh it wouldn't be enough to fully uh determine and the the main reason for that is uh 10 init code other functions and um if it can collab your functions should those be marked in its code as well or not and this discussion was quite long but what we ended up concluding is that um the init code is a flag doesn't seem to be a good enough solution um so our proposal is to not have the flex field

and they haven't agreed on what is the special value for the non-returning function but we would like to have a special value to you to Mark a non-returning function and this value would go into the number of outputs and the two options we discussed is 0ff so all bit set or 0x81 which means the top bit set in the lowest bit set and this option would would signal that the top bit means that we are talking about flags and you know we we choose the first flag yeah that's our proposal to choose either zoof or zero x81 and we won't

have a special Flex field any objections is that okay with everyone that was written down or is that a new approach to the flagging no this these were one of the the options we discussed on the last

call as well so there's nothing okay it's been packing sorry go ahead Alex yeah this was the the document we discussed last time and out of this yeah it's a use special value 0ff or we use Reserve bits as Flags so that's the 0x81 yeah I think out of the Epsilon team it was only me who was leaning towards

having like a dedicated Flex field with pick bit packing everybody else was leaning towards not having it so you know that means from Epsilon we say we don't want to have the flex field on Tesco I think we should make a final decision on this call is anybody strongly in favor of having the flex field doesn't seem like anyone feels super

strongly about it so should we just go with the on flags fill the pack in just the zero xff yeah I mean the question is through FFF or or 81 which is the value we are going for um I'm not sure Pavel because Pablo or Andrea you you guys had a strong opinion so maybe you want to you know what's it now

yeah I don't have English but very strong very slight preferences eight one because it's just like easier to add some additional special Flags the only difference is either need special value or maybe there will be case to have a set of of properties so that's what it's better but it's it's also it's also like harder to explain why this value has been chosen so I'm I will be accepting any decision but if you want my preference that's a bit into this direction yeah that's fair

I I do like zero x81 for the forward compatibility the ability to change it add more things don't you still have that ability the top bit set so in the future you can always say if the top BET's set then the rest of the bits mean something uh I don't know if that is the case for the the xeroxff because I think 0xff is just this is a value because output is only one one byte

but zero x81 applies to me is that we might use all the space from negative one to negative 127 if you're looking at a signed in approach to it whereas oxf means we're just working from 255 down I'm taking up spaces as we go um so I think 81 would be a bit clearer and that we intend to have more special values in the future it's also not necessarily just about us like I could imagine if there is the ability to have more special values than maybe other implementers of the evm try to add more functionality

so if we give them those tools I generally see that as a win anyone strongly against going with 0x81 I think that we should probably just go

ahead with that formatting so okay with you Alex yeah I mean I'm the only one who probably prefers having the special flag field but I'm not like you know as strong on that to Champion it anymore so yeah I'm fine with 81. all right let's let's do that I guess that's probably the end of this spec updates that you had there's a couple of things we talked about circling back to do we want to take a moment to do that we got six minutes yeah there's no no more spec

I know you said you wanted to Circle back and talk about eof2 uh there was one other thing that we mentioned I'm forgetting it now do you remember just give me one it was becoming too noisy yeah I think what we were arguing

whether we should go directly to 2.0 or not and the 2.0 what it involves is the create uh codes the return some kind of a return or code a create transaction or some kind of a a create pre-compiled so to say and I'm personally leaning towards more of having the the create pre-compile option because that means we don't actually

need a new transaction type and that likely reduces the surface area which then increases the likelihood that we can roll this out at the very same time um the the risk with having new transaction types I see is that you know we're going Beyond just evm changes into you know many more layers which um seems to be risky um you know in terms of complexity um but maybe the the example of 4844 with all these changes is like a counter example that you can change like every single layer in the same protocol

upgrade it is possible but I think it's a fair point of view and I'm you know I'm not really sure how things will shake out given there's a lot of discussion about this sscification of el data structures one of those things is trying to figure out what the transaction format looks like uh going forward and there's a couple different camps but yeah trying to change those things all at once while adding new transaction

types it will be pretty challenging but it might also be useful at least just something that's part of the discussion trying to think if eof did have a new transaction format does that transaction format fits nicely within the world of the SSC transactions that that's being proposed so I guess that is to say that this pre-compile is likely the least resistance way of going forward but thinking in terms of eof

or create transactions for the eof world is at least useful because I'm sure more things will come up in the future where we want to add additional transaction types and if the new transaction format doesn't support it very well that is kind of a failing of that design any other thoughts anyone feel strongly though we should be trying to go down the transaction path versus the pre-compile path

or any other thoughts on eof2 who Among Us is is deeply enough involved in the SSC discussions to uh the liaison on that uh probably me because I don't know if if we're working on the new transaction types then yes let's let's get it done so for me if we're gonna do by what's currently called pre-compiles it opens up a can of worms because there's a pre-compiles we could always used to do through evm code but now we got

something we can't do through evm code and we're publishing system barriers I mean I'm fine with that but it's it's newground that we should make sure we do correctly so yeah the the pre-compile I mean yeah I may have been a tiny bit misleading so even the pre-compile option requires some changes to the transaction format but not as severe as introducing like a special create um I mean all of this is written down in in this uf2 document but I do understand the document is long and confusing so likely it may not be

clear enough what is being meant um but some of that is under this heading um in short what this means um that we would have another kind of create instruction like create four or whatever uh which gets the init code from a transaction context and the change we would need to do to the transaction formats is the way we have you know like the blob blob data in the in the 4844 transactions we could have another list of of blobs

and these are init codes init code blobs and this new create instruction would take an index and index into which um which of these init code blobs is being used from the current transaction context so that would be the um you know the the size of the changes um and this is against the option where we introduced like a special um create transaction type and the the main reason I'm leaning towards is just the complexity of having a new transaction type but also for more for compatibility reasons because it seems that now transaction types are proliferating

there's just you know a new transaction type every single year and this doesn't seem to be a sustainable path if we would end up with proposing this option I would actually go strong in the you know SSD discussions to state that this new like 4844 transaction type is only for uh in contract interaction it cannot be used for any kind of creation and it will have these like init code blobs as well and in that Paradigm we only have the Legacy transaction types which are as complex as they are today but this new

unified transaction type will only be used for interactions and it can have a number of different hidden payloads used for different meanings uh we're a couple of minutes over time now we should probably wrap this up any last comments just the one I made in chat that anything we don't get out in Cancun it could be years before it gets to the main chain

including comment I think in the next next implementary call we should uh dedicate it to the eof 2.0 discussions and I think we will work hard from Epsilon to actually post a document before that but let me know if if you have any any other like strong opinion and we shouldn't pursue like this you know transaction Direction I was explaining okay yeah that sounds good thanks a lot guys we'll have the implementers call number 10 in two weeks I'll post the agenda for it

hope you guys have a good rest of your week thank you bye-bye goodbye thanks bye