EOF Implementers Call #38

Transcript

and uh let's kick off maybe with the client updates as usual um so maybe let's hear from Basu first have T are you here sorry I was muted um so for Basu we have all of the uh EOS implemented except for create 4 we don't have the transaction in our eof Mega eof branch and I don't have the code written for it yet but I do have create 3 um I'm written in I have exchange I have uh contract copy or not return data copy or

return data load whichever one it is and um the return contract and those at least U Loop through through most of the reference tests um some of the reference tests are it's touch and go to figure out which reference tests are up to date and which ones aren't and which ones reflect the currentc say the spec there's like you know four different PRS and I'm not sure which ones to pull in and there's even some um I think some of the fills are incorrect because um one of the older uh PRS has um Legacy still delegate calling in has a legac not delegate call has Legacy still um external code copying incorrectly into eof um and getting the full value out of it rather than the

specified values so um can't get a clean run on the reference test because at least some of them are out of date but that's our current status okay so I think the tests have several branches and PRS as you have noticed and uh is a summary is that one branch um I always get confused with this so maybe Andre correct me one branch is sort of following the um New create model which is e create and TX create uh whereas uh there's also a branch and tag which ev1 Master CI uses and that for example contains uh

changes like the ex code copy I once and ex code in general and also um one other thing which I can't remember right now so it's it's a bit complicated I would say I think um I mean it's a bit of a bad experience you can't say here's one branch these are all the current and correct reference tests especially being held back because one client doesn't have all the stuff implemented so it's kind of kind of feel bad yeah I have the same feeling I have been struggling with this but I think for it's a bit contingent on getting the create

um re and at least from my perspective it's a bit contingent on or blocked on getting the create Branch mer in e one because that has already gone into the develop branch of tests if I'm correct yeah or at least partially yeah it's partially gone into the develop tests yeah I'm not sure how to resolve this except like moving forward maybe and trying to get retest at to generate test from the filler is just a giant pain in the neck I'm I I have to use a very old Mac that doesn't have current stuff on it and even then it's it's quite difficult and fragile to use to produce tests out of the filler gotcha

um yeah so I I so far I have only been successful to do fill the test that I needed for the nonc create sort of uh branch and and I can share the setup I have I have been using to do this yeah I don't know there's any if there's any sorry go on that I mean that's that's where we're at we're just at the point where we need to get the reference tests um basically in line with reference test and reference tests in line with the spec um there most of the heavy lifting has been done in Bas except for create 4 cool thank you uh anyone else had any any any any response

to the to the test problem or comments I still didn't try to use use to use them so not for me okay okay okay um since you have the mic dragon can you give us an update on rev uh yeah um I have skeleton for new calls and creates I still need to figure out return contract and I'm currently focusing on validation at validation we have like

skeleton of most of e features so after that it's debugging detailing and basically yeah figuring out the details but when skeleton is like done it be a lot easier that's most for my side okay cool um do we need to update the implementation Matrix for Bas and RI are they I have not they're for Bas they cool thank you very much uh for me I updated it last week for some yeah for some APS that are very easy to test at least in the the code

for others like PS and validation I we need to have some testing to be sure that they are like okay maybe I'll we update the eals to be in progress Supply that MH yeah perfect thank you and the evm one um I can say that the exchange has merged for us recently and uh and calls 2.0 are in review and the create branch is also in review Andre can maybe say more about create part yeah not much we for TX create we are optimizing the interface between EDM

and host now uh but yeah needs mostly reviews at this point especially you have create by the interface you mean evmc right yeah I mean MC yes okay Co and um any more client teams um maintainer is are you with the client team is that yes or no okay I don't know

um no so moving on to the compiler updates and we can see that uh uh there are no updates from Viper side and then we have the spec updates next and here I have two updates to share um there has been a change and um there's there's a PR with a bunch of changes for the cost 2.0 but there has been one added right now which is that the mean mean col gas failure is now a light

failure uh which was suggested by Andre I think there was some some support for this I think it makes sense I changed this here and also in our evm one branch other than that there are some like three or three or two other EIP updates in review and do we have anything else on the specs to discuss or update do we go with this change for

with the light failure for below me colleas yeah I I there was no objections and it makes sense and also you and Charles I think voiced support and I think it makes sense for myself as well and I think and I think yes I mean if there's any objections then just let us know uh I just want to expand a little I think it is good to match the implementation so like if the implementation doesn't actually need to create the call frame then you do the light failure which I think is what the spec does but I'm not sure the

spec U before the update that this in review right now said fail with an error and it's sort of sounded like a hard failure um the EAP 7069 and I think that was meant there but now after after this PR to EAP 70 69 merges it will be a light failure okay any other spec uh related

questions comments topics to discuss okay I just wonder about this uh this call gas U so uh because we don't control the gas as as the argument of a call right so I wonder if this this actually not like a kind of back door to to intercept or figure out some information about the gas because uh if the gas is below this this value and you make a call then it

has like observable difference in the behavior ofm comparing to like the other the other scenario I'm not sure this is very useful but somehow it kind of leaks this information outside yeah but you also pay some gas to to this check um so would do you see a scenario where someone can actually well I don't think this is very useful but sometimes we are surprised by

uh creativity of people yes I mean it's I think it's what is the current value like f five 5,000 or something this is the minimum retained gas okay so so the I think the gas logic is that the message the call message is going to get the um sorry the other way around the the the color is going to retain either this 5,000 or this 63 164 of the available gas that's what the color keeps and the

col gets the rest and if that rest is not enough for the col gas then it will do the failure which we are discussing which is right now the light failure yeah yeah so it would it would take a lot of calls to to figure out the gas available you basically need to can you also distinguish it from the other light failures no you cannot but I mean yes you can because if you know that you're not incredibly deep in the C stack and you have and you're not sending any value then the other the only other

no it can also also kind of um introspect the call stack depth right like if you get a light failure you know okay like you can already tell that the the balance checks so we can ignore that but uh if you get a light failure then you know that it's either a gas issue or a stack depth issue with a W or a presumably you control the call at this point um because a revert also returns one right right or it could be a revert but like you could uh always you

you can do like a call to the empty yeah yeah if you control the col then that's also out of the question and it is only called that stack or um or gas I mean I personally don't have like the yeah you can't disting spending some time thinking about if I mean what what's the worst case scenario that could happen when someone knows how much C was sent let's assume it's possible and just someone gets the knowledge

by some intricate false but wouldn't it revert anyways what do you mean uh like if you if the call frame were actually um created oh I see it's like um I need to think mhm yeah maybe maybe Worth to keep it the back of the head and think a little bit on this so if anyone thinks of a way that this can be exploited then just just um let sow in the in the pr otherwise it

seems to be preferable to give it a failure um I've actually always been like hesitant about having the light failure anyways like why do we need it we discussed this last time I I can't remember what the conclusion was was it like I think the conclusion was uh it's called yeah but like it makes sense to me in a way if you think about calling a contract you kind of just want to know if it's a user revert or

not um I don't know I don't have any comments on this like if I think about actually like using call2 and trying to find out if a user if it's a user revert or one of these light failure conditions like I start to cry inside because uh like I don't know can you actually tell if it's a user version well we kind of I I'm not sure what is the current

state is but we wanted to include this information um I I think in general this is really really delicate topic because like call are complicated um so even for gas I kind of imagine that we could make some kind of like table that shows what is the current gas behavior for the calls like I mean how much gas is actually consumed on the color side how much gas is passed to the to the col how much of this gas is burned at the cost of it and I think maybe there's a

way to kind of visualize this because even for for KVM I have I I wouldn't be able to answer this right now without checking the the code um and maybe just kind of works as a kind of visualization of what's going on like where gas is putting how much is like what are the requirements what is the minimum on both sides what how much the minimum the C gets how what is the maximum the col gets in different cases and maybe we can do the same for the for the f for the new calls and see if there's any like something doesn't look right and I think it's it's also

Worth to get feedback from from compilers and uh like mostly contract deaths because yeah I I don't really I don't feel as someone who actually ex actually uses the Calla often in practice so um I imagine that solidity is most this user like user facing um semantic they they mostly convert the light failes into hard failes anyway right that's what I remember from some years ago but uh so wonder if this makes sense for

them to either expose more information or maybe do just like default like single Behavior that's expected okay do do you want uh uh do you want us to make such a table yeah I'm not sure what exactly to put it but I can also try to do it yeah it's for the current VM for example let's see how it looks yeah it can be quite complicated it I don't remember about Charles

whether we have answered this or not if if the question is why is this like this call stock limit light failure I I don't think there is like good answer to this it mostly comes from like the one of the first implementations of evm and yeah someone put it in the place that was was just working like this and similar for yeah and similarly for the Creator some cases that it works this way and I

think it's in many many cases it just comes to the fact like who and exactly at which points like where exactly in the code someone implemented the check because some of the checks will added later for example I think the the call the call stack limit wasn't there in the first place it was added after some like audit or stuff like that so mostly I think that's kind of likely explanation that someone actually took this result of the audit and added the check and it happened to be the place in the code

that sorry you said was an audit yeah yeah the very beginning before it like maybe if we know who added it we can ask them but no I mean it wasn't I think it wasn't so so detailed I think the the recommendation was to add some limits to the how how how deep the the call stack is right so that was kind of the the suggestion and and then the the like the developers decided okay let's the limit will be 1

1,24 and let just add it and someone added and generated test and the rest like followed by this mostly that's happened I think in many cases about if you try to explain some of this evm Quicks I think mostly this is the the reason in in many cases I mean I would I was always thinking that not creating the callif frame was the criteria that if you don't don't do it then it's should be a light failure but I just realized that the static static check is a hard failure static call so we cannot

um um you cannot send value external call from a static call context no what's I always keep forgetting what that is uh it is static mode violation is when when the call has value but uh but we're in static mode so yeah I so when you're static calling and then calling calling and you send value in this second call then that violates the static of the original call but that's a hard failure I didn't realize that you can do a call from a static call context well yeah you can provide it you don't send any value because that's a

state modification otherwise it's fine provided like the underneath call will not modify a state as well and right yeah that was the reasoning that someone has because static call was much later than the original right and what was the rationale to make it a hard failure that maybe that could shed some light well if you like sore a static call I think you get a hard you get an exceptional

failure yes but here we're in a we're doing an ex we're we're doing a call and we're not creating the call Le frame so why is that the value transfer happens for the caller frame so if you do the same rules then it's like a set balance and the set balance is actually the thing that throws the exception um no I well no that happens the check is at least in evm one it happens before the the balances are touched I think but the balance change

happens before the call right does it I don't know I'm looking at the view month so this is not a good example oh I mean like I said I think the the status code is like most useful to find out if it's a user failure or not and if we can't tell if it's a user failure or not then maybe we shouldn't even have the static I mean the status code what is a user failure not supplying enough money supplying money when it's static um someone throws a invalid later

down someone throws a revert later down it's a user refer so do we have one status code that's related to calls within the operation and the next one for anything coming from the context and that sounds like what it's circling the drain towards what it is right now um with uh um the not the static money check and the nof money check being an error within the operation which would be the light failure versus an error from subsequent execution which is the number two the heavy error unless it's a revert

right well the only way to return failure from a call is to revert or invalid there's a lot of ways to exit from a call that you can stop yeah stop is valid return is valid and those return zero or those return success return one change the state in a statical context um that an error um that's that's the that's an exception in the process that's not a deliberate attempt to return right exactly so like it should tell you what the user intent is

like you either had a regular return you had a revert or you had an exceptional hold at least that's like what my smooth brain like idea of what the status code means and then you know I can imagine like being a user and like implementing this and then finding out that you know these light failures are also bundled into the r and then it becomes problematic but then there's the inertia I don't know what's what's more important like but the inertia is one or zero like if in this distinguishability kind of

argument what we give every failure style it's own number like that's the opposite Spectrum yeah I think if we want to leak less information it should just be um then we should move the light failures into the um exceptional into the two status code two and like you can't actually tell I don't think I think if you move um those into status code to then there's not very much you can introspect so status code one comes from calling the revert operation or the invalid operation and status code two comes from

everything else only only rever in the in the C frame yes only revert will give you one so one is only when there is a revert being passed for the parent and literally everything else goes into two yeah well and then called call stack depth the balance check and the minimum call yes from today on that also gives you one one which it is messy I mean it sounds like what people would want to react to was did I throw an error or did something that I can't

control went wrong um like a VM eror like you know out of memory out of Stack static call I think that's really what they want to distinguish am I throwing a you're not the owner of this contract or am I getting a you use the wrong syntax on this op code additionally uh people probably want to differentiate between uh are the gas spent or did it just like reverted not reverted but like light failed if the old gas is spent for the stack or for stack like that that means that you

will have less gas to continue your execution well we're trying yeah I mean I guess it depends on if if gas introspection if like gas should be observable or not and if the point is to like remove gas observability then like you shouldn't be able to do that [Music] okay I think I I concur with Pavo that we need a table that will just demonstrate the current status and I would love to list out all the contending ideas or or

layouts of this because I mean these various returned status codes were introduced to be different but in a way right right now we're not we're not uh lever we're not um like the differentiation between 0o one and two is just just messed up in a way so maybe we should uh like spell this out in in issue which I can open somewhere and uh just visualize the current status and then visualize also what we what we would like to have like the arguments make a

survey um yeah I can I can open such an issue and try to also work with yeah uh right um okay uh so maybe um let's let's stop here before we have this uh this visualization ready to kind of focus the discussion and before we go also there's

Aman from nind um he joined later uh maybe would like to give an update on the stles of UF NE mind uh hello can you hear me yep welcome okay perfect thanks uh for eof our implementation is still kind of similar to the previous update we just did the changes that were added to the spec and uh yeah like the reorder of simple stuff that was added to TX create and the renaming of up codes okay that's most okay would you like to uh open a PR to the implementation Matrix that we

have to um uh least stuff that you have ready okay so which we'll run the test again and see how we are and then we'll pull a PR for that I'll just send you a link to this uh to this table so you seem to have a lot of stuff ready but um the nether mind row is still empty in the table you've got this in the zoom chat okay perfect perfect cool um thank you for the update um do we have any any anything else any closing

comments okay if not then suppose thank you thank you all and um um Charles well I just wanted to ask if Papa wanted to discuss the change thing but we can do that offline because there SE a discussion on Discord Right started yeah I I don't think I have anything to follow I think it's more

less satisfaction from my side yeah kind of one concern has about the name but I think it's not really important if you decided to name it as it is I think I'm okay with it and the example I think yeah I kind of understand more how this is useful I mean if you want an example of Stack traffic um something like you know one6 of all I need look at the chart but a lot of it um a lot of time spent at evm and real operation spent just moving

stuff around on the stack and my hope is that exchange would get rid of some of that because there's some patterns where you you move it to one and then you move it where you really want it move it was 2 one back to that stuff and that's what was um shown on the uh on the Discord and um just some some of the bite code I've been reading I do think that solidity also runs into the stack traffic problem that exchange could help okay it seems like exchange is under control um any anything

else okay then thank you very much everyone and uh see you next week thank Everybody by thanks