EOF Implementers Call #52

Transcript

all right I'd like to welcome everyone to eof implementor call number 52 um as a remind before we get too much further into this call we're going back to the every other week schedule so there will be no call next week um there will be a call in two weeks and I may be uh on a family vacation that week so someone else will need to run it I'll try and keep my notes available I might be able to make it I can't make promises um so that's um Wednesday morning I won't be able to make it okay so in two weeks I won't be available but I think there's going to be enough people that it's still worth it um having it there's a lot of progress being made right now um agenda

for today client updates compiler updates spec updates testing updates and other items and there was a couple of late things that came into the uh agenda we'll discuss uh evm t8n in testing and finalize some of the eof create stuff um so client updates um I'll start with Basu um just keeping up with the uh State tests um making sure that we're uh up to date and when we see differences fixing them there hasn't been any um notable change this week um I'm still trying to get most of the reference tests

in um evm one we have merged the new rule to validate that container is below maximum in code size and another thing we've merged validation of init container rtime container kinds uh except we still haven't merge the part that disallows unreferenced subcontainers so that is still in progress uh but I think we'll be more soon too um yeah that's all related to impation okay um never mind

amen hi we have some can you hear me yes I can hear you perfect we have some failing tests regarding EF create and X call up codes and we are trying to figure out what's going wrong and fix it okay need help feel free to Ping up in the chat I could probably help you out if if you haven't figured out but I don't know NE mind code that well so it might not be too much help um sure thanks G Marius um yeah I've been going through the um the block test I still haven't

figured out how to make the state test work but they they're testing the same thing so it doesn't matter um I could just go through the block test um and I found I think like 10 issues already um right now I'm stuck on some gas differences um and those are kind of difficult to uh to pass uh or to to to debug in my opinion so if if anyone else has a passing implementation and could trace some

stuff for me that would be really really helpful yeah I I I have no overview of how many tests I'm still missing but um shouldn't be that many anymore okay I know Bas an ev1 agree on gas costs I wound up rewriting all of our gas charging logic special for exd call rather than trying to make um the gas logic work for e and current and ancient Forks there's a lot of interesting steps in there especially the pre- Constantinople and preious dragon stuff so that's that was our experience in bases we just rewrote it

special um because it's to get rid of all the the previous Flags do we have anyone from ethereum js on the call how about wre or um Aragon okay any other any other thing that wants to be said before we move on to compiler updates from the eeld side so just wanted to uh give an update we just started

implementing the EF eips we're just like halfway through and uh I'd imagine we would be like uh uh we would have a full implementation in a week or two weeks is what what we attacking them okay what I'm sorry what client were you from I missed that part sorry E from the eels team eels eels okay great yeah eels eels will be important for chest because that's basically the reference implementation so yeah again if you got any questions just feel free to pop them up in the chat sure thank you I need to add eels to my list okay um any compiler updates I

don't see uh Viper here I don't see Charles and I don't see from solidity we are going to be revisiting one of solidities requests in the spec updates though any compiler last call for compiler stuff great so um for spec updates um three things on the agenda item one is to revisit EXT call return codes um one is to look into adjusting the stack Overflow check and call F jump F and one that should be easier is to finalize no shared containers between create and return contract

um so the first one was exu cering codes and this is kind of heing back to um a few weeks ago when we had the solidity team and one of the issues was there's no good way to identify an eoa from a nonoa account and I think what we settled on was well we don't need it for AA and I think a piece we were missing um is one of the requirements from erc721 um and this is for the safe transfer from for the safe transfer from to work the contract needs to be able to identify if it's calling a smart contract or if it's calling an EA even if it's a smart contract wallet so um yeah I think this is a non this is this is a use case that

still persists past um living in the future and the the point that was made in the linked form uh the linked eth magicians comment is we can't create a spec compliant ERC 721 nft and eof as long as as this is the case um so if it's a smart contract they have to do a call back to it um otherwise they can accept it and the point of this is to make sure they don't send an NFC to Smart contract they can't also send the smart contract back there's a check where you have to have a supported uh supported call and has to return us a magic number for it to be

valid so um anyone have any comments on this or content before I go on to any proposed Solutions okay so as I was going through with this I was thinking one of the ideas we batted around to deal with this was to EXT call return codes um this is something we talked about in Niota um and this is the variant of that that I have posted here is basically we would distinguish between successful calls to Smart

contracts and successful not calls to eoas and this would be we still need to be able to do EXT call to the eoas to do um balance transfers and we can't just segregate out um pay an ex T because there are a few use cases where a call needs to receive value to be successful so we always have to be able to transfer value um so the thought was rather than one success code we would have multiple success codes and we would spread them out so you could do a more simple check um if you only are concerned about a successful call you could still do a zero but if you just concerned about success in general it would cost you

about four more op codes three or four more bytes um is zero and you might be a not in there but it might cost you three more bytes to do a check to see if it's greater than zero um so it would hurt a little bit on the call Overhead if you care about non- calls uh but this way would provide an opportunity in a mechanism for EXT call to figure out if it's calling uh contractor in EA so um anybody's thoughts comments on this anything from ipsilon Alex Peter

Andre yeah I think it's definitely worth to change now given that there's this new use case specific status codes I think maybe will have to think some more I'm not sure yet what would be the best yeah we discussed this already but there were and there was several ideas I think are there other ideas we you pursuing rather than just the return code how how about if we put the successful non call case into revert category would that be an option I in to return one one is

inverted if it reverted if it you know had the problems that there's this bunch of cases where it returns one and also for a successful non call the rational is that they're somewhat similar I mean oh well they are not similar because a value trans might have happened so no I guess not right and in that case the value transfer is what they're looking for yeah okay just do a value transfer did a value transfer and call right don't do value transfer H in the nfts they it's not

about value transfer right but we still need to keep the case where EXT calls can do value transfer and we need to be able to sting when those were successful because we don't have the payop code and if we put the successful non call into the uh upper register so to speak so I don't know 253 mhm uh wait that doesn't that doesn't help

really yeah because they're trying to create categories of where these broad marks are so when you do a a return test you can do a simple comparison yeah and negative-1 um you 256 um creates a much larger set of bikes for the comparison if you want to see if you inverted versus failed because the other case is we want to if we're going to give this information we need to expect that some codee's get to differentiate between failures and reverse which is why I opted for a single bite of encoding rather than all 32 bytes of encoding um because that's going to be harder to uh efficiently store in it uh how about uh pushing two items to the

stock one for success or failure and the other whether that was a contract or not there's no such instruction yet that's why we kind of and not going that direction but there and then every call is gonna wind up having to put a pop on if they don't care y yeah yeah another option is we could put an OP code that we could ask has contract data because that's what they're doing with size um is they're checking for it there was the other option on the calls to have like an input flag where to allow yeah no execution input

flag would it be another stack item or would it be like a bit part in one of the stack items I mean good question because we have the address we have the address we have the value and we have the two inputs for call we don't have the value in static or delegate static and delegate might have the same issue because we can't just rely on the successful on received return because an

EA is not going to send that the the one issue with the input flag we also discussed it like a year ago if you have an input flag then why don't we make you know the static call and delegate call also just a flag and have a single op code so it's kind of yeah that would be another useful flag yeah but if you introduce a new OP code then wouldn't pay be or transfer be

the the actually useful one as opposed to have like two versions of the call um how would you distinguish um calling the um on receive to an eoa from a contract if we allow pay that still doesn't solve ERC 720's unique need to figure out um am I transferring it to an eoa unless we make them you know keep sending uh Satoshi across or ways or whatever they're called um to the Target or doing another um trial call to see if it's uh going to respond to

anything because I think this is like a legit non a legit case where pay doesn't really solve the problem yeah I mean it doesn't one thing we might want to consider is bringing back the XT code size with a change it doesn't return the actual code size it returns a one or zero if the code size exists or if it doesn't exist and that would actually solve 721s concern because the the actual

encoded um standard for if it has a smart contract is if the code size is zero but wouldn't it be rather like is EA or H code that's basically is eoa and has code is what it would be because code size is is a very standard solidity check they check the size for his code and they don't care about the size in most cases but then you could you could just call it you know EAS way or has code instead right I mean would that be a valid um transfer case like uh what randow

replace difficulty would that fall into that category because it's backwards compatible across the two of them we're looking for a zero or a nonzero value from a contract so we could reuse the code size and rename it is theoa no is is contract so if it returns one then it is a contract if it returns zero then it's not a contract address and that translates fine back to Legacy because any length of code is going to be greater than zero and we would encourage implementers to test zero and non zero rather than zero and

one even though we're specified return one and we didn't really have a mandate to solve the eoa question you know with the we only had like reduce gas uh introspection and code introspection but I wonder if uh because right now we we can of hide the fact whether something is in eua or not which a lot of people wanted to achieve for a long time time yeah I

wonder going back on this what other issues would it open I mean definitely solve like this case but yeah I have no answers right so maybe we should think about this for a couple of weeks again and consider the two Alternatives um is contract and return code changes um his contract is clearly the less disruptive change to existing implementations um but I think we're not too far along um where we could do this level of a change if it's warranted so I think that's what you to think about in the

next two weeks and probably hope that um Charles or Daniel from um solidity comes on the next call the the the one uh the one piece I'm kind of worried about with changing the return code is that how frequent is this requirement I mean obviously with nfts it is um but you know have frequent is it across all the calls because in this case we're optimizing for NTS and every single other call has to has to make checks you know with the the new version

of the return codes because the old version or the current version it's just a single a zero check right and we're imposing this requirement on everyone effectively by increasing the successful return space Ric I think going to be back next week so maybe we could um we could at least think about changing the solidity uh the compiler implementation

to to both cases so we can see what is the overhead on some of contracts benchmarking that would be an excellent thing to look at yeah absolutely because the contract is like zero overhead is existing overhead I think we only need to see what changing return codes would do to it okay all right so we will document this let radic look at it and ask solidity and Viper to chime in on the two options uh does it simplify it in any way if we use bit Flags bit flags on which field like an immediate

to the call or is an extra stack item the return code so that's kind of what we wind up doing here the high bit would be failure so that's why I coded greater than 127 the high bit signifies failure the low bit signifies non-failure I don't think bit twiddling is going to save us any um any op codes because we'll need to push 128 do an xor and doing a zero so it's already one worse to do bit twiddling so doing a check doing an LT on 127 is probably an LT or GT on the barrier is probably more efficient than

a bit field but I don't know what other bits we'd want to encode I mean maybe we could encode the second bit's always going to be that the call was to a contract or non-contract or you know we could do it 64 and have the next bit be the contract or non-contract flag and then the remaining six are the status codes and that still preserves the 127 feature um something to think about um because we could we could go encode more useful bits and all sorts of things on these okay I I'll add that into my write up about return code

possibilities but I don't think we have a solution today and we need to remand it out to uh others to discuss um next item um was to improve the stack um on KF jump f um and that is an issue by Paul Paul is he's not on the call is he oh Peter he's not Peter Peter could you talk to this um yeah [Music] so so there's this um I don't know call it convention that the

max State height ma Max stack height in the header includes um the inputs of a uh code section and um when when you uh how it goes when you calculate um the uh oh how to best put it Andre can you can you maybe sort of yeah this is related to St overflow checks at runtime so this check happens only

during call F and jump F and it checks whether Max St height of the cold section is plus current stack is above uh stack Limit Oh yeah and and the like minor issue is that Max stack height as we Define it currently in the type section it includes uh sections inputs and then when we calculate this stack Overflow condition it has to subtract this uh number of Target inputs because otherwise it's counted twice they are already on stack and they are also counted in Max height of the code function so the um the check is actually

if current stack uh plus Max stack height minus inputs is about the limit and so this is Clumsy one reason and like you requires the ex extra access to the header to get these uh inputs uh of the target section so the proposal was just yeah to redefine Max de height to not include the Target in inputs um and yeah this then this check is simplified and maybe we should then re rename this this field it will be like

not Max high but Max growth or Max St increase so that's P's proposal I guess and yeah I think it will maybe change many tests because like the all the tests that that have inputs uh and call F and jump F uh and this renaming I'm not sure what are they um what what's the impact it's just probably just renaming in the spec but also I don't know all the variables and implementations okay so everyone would need to rewrite some section of their um code validation um it would impact just about every single piece of code that

uses CF and this is to get rid of an extra subtraction in a stack height right yeah I see the Aesthetics but I still am concerned this might be in the too late Department yeah it's yeah I'm also thinking it might be too late so it's not only about Aesthetics it might also affect veral future and like it requires extra access to the header maybe but it's like the the two bytes that in code this are just next to each other yeah that's yeah actually it's more about

managing after you have done the access you just need to keep the extra variable around right I mean is it likely that Max stuck height would be in a different chunk than the inputs I mean it's this it would be the the type data in a lot of execution would probably be lighted we wouldn't see that because it's not strictly necessary because it's been validated if you're doing a call if it's been validated you're passing in the correct amount of variables because then when I view through when when I war game out

what what this is going to look like in a vertical format I don't see us ever bringing in any of the the type section I mean I'm sure there's optimizations you can do if you have the entire code with you but from a witness execution it's been validated so we just presume it's correct what do other clients think about

this never mind uh gu no opinion strong opinion Aman said in chat feels too late because we're not losing the data we're just having to do an extra subtraction so I'm thinking we should pass on this

unless there's a strong reason we need it any comments on that if there's no objection perhaps we should move on to the next item then on testing test her max. need to be updated all there those can easily be updated the test can be fixed and that's just a long day of running over failures and and fixing all the numbers but this wouldn't be wouldn't

need to be done urly because I guess testing could just do this abstraction right and then that can be worked on in future I would just change the test it shouldn't be difficult to no I mean yeah fix the test it's only the tests that do call F and have inputs yeah yeah there shouldn't be many just just as a stop G solution you can just you know um anyway I'm concerned this is a lot of

work for um a change to drop in minus from validation do we want to come back to this in two weeks and so we can talk about testing or come back if there's time available there's some testing issues we need to discuss yeah let's come

back maybe will be present in here okay let's table it and get yeah Paul's opinion I think that's that's the big thing that's missing um quick small one finalize the change to just allow referencing the same container by both eof create and return contract um within the same um we had discussed this before so this is just the final call if there's any objections um even though there is a corner case you can share revert it's just not terribly useful and it's easier to prevent it and it prevents problems yeah it Sy things I think it's

okay um so let's adopt this unless there's an objection that has risen been out for a couple of weeks now discussion for this okay um our next question or evm one implementation okay here's the a bullet so yep um so what we need to discuss I think going on to testing um is ev1 t8n State tests um Hugo do you have anything you want to tee up with this or no sorry Mario Mario yeah so um basically the evm one

tool is currently um appending the Bon root contra contract State changes into the storage even if the contract is not there which goes against the spec um I think that should be easily solvable uh on the even one side but I think the other thing that we can consider is basically just add a a status flag into the transition tools which would mean that when we call the transition tool either gets transition tool or even wants transition tool with this flag uh um uh the return the execution that the transition tool has to do is um it it it doesn't contain any

block uh level operations such as the um withdrawals um such as the block hash inclusion into the uh into the history contract and so on so forth um I think it's e it's it's not that complicated to do on get's um codebase um and this would simplify us having to work around uh uh when we fill the uh the the state test versus the blockchain tests right now what we do when we are filling the state test is that we simply do not include the the history contract without don't includ the beacon route contract and that means that um uh we expect that the transition tool follows

follow suit and does not uh execute this this logic uh but if we specifically set the state status flag we we now have like the uh the security that the transition tool will not actually include this logic um so basically yeah that's that's the question I think I think the this flag should be should not be that difficult to implement and it will help us when porting the EF uh tests into into PRACK because we now have like four new um uh predeployment line flag or would it be uh data passed

in the EnV or something um I think a flag should should suffice a command line flag and so yeah um Bas who runs in server mode for performance reasons would test keep a separate server mode for um one or the other setup or would it tear them down and build them back up each time that's that's a great great great question I think for besus a specific case we need to pass it somewhere in the in the environment um so maybe we can generalize this and just pass it in the in the environment uh for everyone okay so so there's a flag

no block hash processing if it's in there's no block hash processing no Beacon R processing no withdrawals deposits or consolidations to be considered um in the transition tool if it's present we not need to consider all of them that's what it exactly okay everything that is not part of the transaction so the ideally you only execute the transaction and return the state root modification and that's it okay I think also you you had you made this suggestion some time ago um so I don't know if you if you have any

comment but um but yeah I think I think going into the environment the flag should be U should be pared and then just select the mod that you're going to execute and that's that's about it okay any opinions from evm one NE mind or gu yeah I think should be pretty easy to implement for us okay can you create create an issue in1 Mario yeah yeah definitely um I can also create the pr for for G um but if I need help I I'll just

sping uh someone from the get get team okay Aman Marius what are you what are your opinions on this doesn't seem yes Aman go ahead uh I was saying it doesn't seem too complex to add so we'll try to add it okay yeah IE I prefer it in the test environment

okay um yeah so basically actually an environment too so it sounds like we're all on board with it um I'm not thinking it'll be too terribly difficult because of stuff like eth simulate we always want to be able to execute transactions outside of the block context so I'm I'm hopeful that the client teams won't have too much difficulty implementing this okay any other testing updates from Mario now that we got the most critical issue out of the way um not that many I know there are uh a couple of PRS open I was uh focusing on devet one uh eips yesterday and and the day before that but I will try to get um to review in the PRS uh today

also there was um modification U that was suggested by Andre um about uh having the init code flag um this this change I I have a appear for that basically this change is um whenever we call the even1 dash uh UF pars tool now we're passing also the init code flag if the container in the test specifies that it is an init code uh container and also when we generate the fixture the E test fixture it will also contain this flag uh in the Json in the generated Json so when you are consuming this test and if you see U inside of any of the vectors that the file contains

you see the init code field set to true you should treat this uh this uh the the bite code of the container you should treated it as an an e init code container um yeah that's basically the only change that clients need to be aware of when they uh they consume this tests okay and that kind op code is um going to be at the same level as uh the results right it's going to be code results kind is that the level it's at uh so it's uh right now we have like uh we have the vectors field which

contains a Serial uh an increasing number so from zero to n vectors and inside of each one there's a dictionary and that dictionary will now contain the init code code field equal equal to false most of the times but sometimes it will contain equal to true and then you you know you have to treat this uh this as an init code U container okay so the name's gonna be in nit code the gonna be nit code okay yeah yeah I I will try to let me I I'll send the pr into the into the Discord with the update to to specify exactly what you guys need to take a look at okay cool um anything

else that is on the list no one else so I'll write up um a summary on call return data and is contract um I think we need to wait for um Paul to uh advocate for CF a little more articulately um and that'll be discussed in two weeks and I think those are the only two open items other than the pr for the the

other than the changes the TA then is there anything that we missed or do we need to discuss the remaining 12 minutes all right um hearing none um we can probably end the meeting then uh we have our uh plans for the call in two weeks again the call is going to be in two weeks there will be no call next week on the fourth of no

the 3D of July um our next call will be on the 10th of July um again we don't need to wait um yeah I don't think we're ready for Dev Nets Barnabas I think that's okay yeah that's a good point we were looking at launching Dev Nets um but it would be a single client devet at this point and I don't think we'll get much good interrupt signal out of that so yeah so it's going to be at least two more weeks for Dev Nets we're going to push into July at least for that yeah I agree uh also kosis is now eof ready so if you have your client uh wants to support eof with eof time it it's automatically going to be

triggered yep I got a local curtosis running I started it up and it started up fine I haven't thrown anything at it but I'll work on getting that the next couple weeks yeah would be good to create some asserter tests also and then we could uh do automated tests in crosis okay I'll need to research out right cryosis test so it's asserter test asserter test yes yeah feel free to reach out if you have any questions okay all right last call thanks everyone for coming um I

know it's summer and there's a lot of distractions so don't forget to touch grass while it's green and we'll see everyone in two weeks see you see you all thank you bye bye thank you bye