EOF Implementers Call #47

Transcript

okay hello everyone and welcome to eof implementers call number 47 and um let's kick off with client updates um first on my list is myself so we can give an update on evm [Music] one there isn't much I guess there we have uh two changes in the pipeline one one is the validation of uh init code mode uh uh and the other is UF creation transaction I think both are in review right now anything else Andre I'm forgetting pav I think that's about it yeah yeah in

it code mode validation is not merged mostly because testing turned out a bit challenging like it's better to refactor validation interface a bit to make it make it easier so we yeah working on that right okay next on my list is uh don can are you okay to give an update on this yeah um our current Mega eof Branch um passes all the tests in the Epsilon East repository um I'm working on getting a merge in a main um that's you know kind of going to be a moving topic into the

main of Basu it's going to be moving talk with the next two weeks as to which Fork it gets assigned my current proposal is to create a Prague eof fork for um stuff configured by Genesis file and in stuff configured by reference tests it'll include Prague eof and in Genesis it won't include it unless you use the Prague fork and my reason is that the dev Nets don't have it yet but the reference tests do um so that's what what might be coming down the pipe but um there's topics on the ACD schedule that might Mo this decision okay thank you um next I can uh recognize mariio from gu would you like

to give an update can you guys hear me now yes very very well perfect um yeah so um as I said uh on the interrupt um our code validation was working but it was suboptimal because it didn't go like the kind of um the work list thing wasn't great and so I started completely rewriting the um the stack validation um it's kind of done but it's not

passing a lot lot of the tests um and so I just need to go test by test figure out where the problems is where the problems are um and why it's not working the way I want it to yep that's it okay thank you do we have any other clients uh participating client teams I mean anyone wants to give an update okay I guess not then compiler updates do we have anyone from compiler team on the call um we don't but um I don't want to

speak for Rad but we have so R has been working on the solidity POC implementation which would be able to compile a couple of uh um well-known contracts and it's working right now I think the main purpose was to compare the B Co sizes and the results are optimistic so far um but I think we're still working on fully I don't know cross-checking um the results optimistic I think there were no C siiz regressions um and then uh the next point up is back

updates do we have anything to discuss here I don't think so I think everyone's burned out from inter up yeah yeah so the one that you taged me on this today pav yeah I think like counted so how how well can you hear me because I'm so mic hear okay yeah I think I counted like four different issues we kind of need to resolve um and there's a different level of complexity um so one that was we

discussed for longer was this uh return data copy instruction uh I think this I think most of the people are in favor of changing this and we discuss what exactly how exactly to do that I think they there were two variants one is we kind of remove the old op code in O and we introduce new OP code so mostly we change the name of the instruction somehow so it's more clear that it is different and the other option uh is to just change the the semantic of the instruction depending if they're running in newf or not that's I think it's slightly in favor of

I mean compilers are slightly more in favor on the um in this change semantic version um so I think that would be nice to figure out uh if we're doing this and like with version because that's kind of one of the longest pending issues and um yeah I'm not sure I kind of also in favor just changing how it works but is it's good enough I'm not sure so I I actually asked G because I

wanted if they have any strong opinions about it so mostly my idea was to collect this comments um so we can move any progress I don't have any strong opinions about it um it it kind of sucks for us because we have to maintain two versions of basically the exact exact same op code um but I understand what the what the compiler teams want and why why they want it and

it seems like a good enough ask for me to say let's do it and by by skos SX you mean both uh variants yes changing it sucks equally sucking yeah okay for background I think we had a bunch of not so strong arguments uh the ones in favor of having a new OP code was that it's kind of consistent with how we treated EXT call and uh yeah I think this this one it's like the main

precedent uh were there any other arguments in favor of the other like introducing the new OP code we had like a big notion of it being more secure like more separated but I don't know if it's it's if it's actually a thing I think the only argument that I came up with was that um we with this change we're kind of breaking how it works and maybe assumptions around how it works so if someone um

like assumes this old behavior and know only knows this old Behavior then they might get be surprised by it um but I don't know if there are any people that really know about this behavior that are not in the room right now um so I would be fine with uh changing this yeah I think that was the main argument so if we introduce new up code at least like people will know inspecting evm they will notice that this is something new and they will need to find the spec what it does and they will find out that it's like the old one but like with a change otherwise they will see kind of the same name on the

trace for example and but I think it's also fine so I I would I would suggest we actually go along with the change so we kind of Speck it out because I think we don't have it done I mean in the E people we have it but we need EIP updates so maybe let's do it uh with the change change semantic and I guess that's like next phase when we will see the EAP updat and then we can also collect some objections I think but I I would move on how it's how it's suggested

m thinking also like about things like formal verification or static analysis would would that not impact I can try read code analysis because then it's then it's dependent on whether it's C or not and maybe some methods don't have that knowledge I don't know just just there shouldn't like I think their whole stuff will be broken by UF anyway so like they will need to look into it um either way so it's like I don't I don't I really don't see a scenario where someone would be surprised by

this and even then discop yes and and even if someone would be it it's probably only to go only going to be one person in the history of everything ever so um I don't know okay then I guess on yeah I I think we like I think we will be fine just changing the semantics of it

okay I think we're leaning towards change semantics option okay uh what were the other things proba we were mentioning four items yes yeah um so other was this init code mode validation I think that's in progress so I think we don't have to spend time on uh but it's kind of the spec is is not updated yet so that's I wanted to mention um there was one more thing which

iash probably maybe I I don't count this one I think it was B Block cash yeah I think I didn't counted this one because seems like no change here uh I think we didn't collect enough arguments to make any changes so the thing with ban block has would be that since there's a new um contract that they're storing it with hashes as part of the system update before all the transactions that we could let eof get the block has from that contract rather than relying on the operation and this would force people to live in the future

um the contract has a look back of 8,192 blocks instead of the block hash operations 255 so there is you know some incentive to use the contract um just before veral ships however um doing block cash in eof will be more expensive than doing block hash in Legacy but once verle ships it's going to be quite a different gas regime for sure I don't know if well yeah okay yeah no sorry I thought that maybe the gas costs wouldn't change with verle but I believe that even though they will keep the op

code alive they need to change the gas cost because it touches the stage right you do a block has call and it implies it requires that you bring the slot in the account into the witness and so we have to change the price or it's going to become uh broken meter attack yeah um I am in favor of not changing removing block hatch because the pricing will change eventually anyways and it just creates uh more friction to upgrading to you yeah I'm also kind of feel it's like

it's better to leave it as it is not so strong arguments to do it should we log this as considered and rejected in one of the eips then um yeah probably makes sense U that's why I created the issue what I can move this to as well should that be the maybe I don't know right section of my whichever EIP we're listing all the laundry list of bandn off cods I think is the right place for it ah this way yeah can also be that would

be like the general list of one up codes is the first TP which is 3540 right now I think it's instruction validation BS all the gas Etc uh maybe I don't know I remember that we were kind of discussing where to put it okay um I'll make a note about it and try to handle this um so the last item I can bring is this uh this creation transaction right

because there was new idea how to do it coming from from P to my to my understanding and we kind of discussed it a bit during inop and seems we a bit like going in circles here but uh let's maybe summarize what's what's going on right now uh in terms of the creation transaction IP is that it I'm sure that was that was written down but mostly uh I think the difference from the current spec was that instead of running this in you remember this correctly yeah instead

of running this in creation mode we just uh kind of execute the code and the there this EF create instruction in the code which will create a contract well that was an idea toss but I think it didn't get traction okay there's some interesting like I think properties of this uh one is that with youf create instruction we only stick to this create two address scheme this this this no ever used this all creat address

scheme for your that's kind of think it's kind of interesting difference yeah let me maybe open up the thread here um there's a disadvantage of requiring salt by the way which is that um you need to generate new salts and there's no non-soft code right so in this case a compiler um if if the desire is to get a new contract of a random address um effectively random address the compiler just could dedicate you broke up sorry

what hello the NSA hello can you hear me godamn it can you hear me yes okay my headphones tied um this solution would be to dedicate a storage slot to become the moving salt um if you need to create new contracts that have random addresses that aren't driven by salt and the user doesn't want to manage it themselves can you not just use what's that uh can you can you not just use renal uh no because you need to like add something every time in the block like you if you have multiple Creations

spread out across trans you know in the same transaction I see yeah okay sorry um yeah maybe that's already yeah I have to think about it because like the the gas of create already accounts for the nons update right so um maybe this is somehow more expensive it's like penalizing people for something that was available before so you would just put a warning in the compiler saying you can save gas by including assault or if it's in the Constructor just apply a default ass salt because you know it'll only be used once those are some options but the user has to keep track of it non too if they

don't have like a input for right like it's solved by having a non-op code which people also ask for but we would also need to burn the nons not just use the nons because what if you do multiple of the same contract I don't understand like every create call or whatever invocation increments the nons right so the nons would give you a Nots and increment it yes which is like exactly what does right um that issues with

3074 in that it's supposed to be a transaction count not just and contract count not just an non increase so that's that's that's an issue there another considered was a sentinel value where if you pass an assault of a certain value that op code could um increment the nons but that feels like we're over overloading too much yeah what's the Sentinel right uh it could also be an immediate because um we have that now which would be a new OP code it's the same op

code then how would you signal a variable immediate it would be euf create plus an immediate but you need a signal with the up code number that you have an immediate that's what I'm saying like the existing EF create would change yeah so that it always has um uh by the way sorry I'm driving so I have to like mute and unmute myself but um another fun thing could be if Legacy contracts can deploy eof contracts I think V presented a variant of this but like if Legacy contracts can deploy euf contracts which are like

start with ef and then know the eof validation rules then we don't need to think about bootstrapping eof contracts we just let users deploy them with Legacy contracts so in achieving the goal of um code isolation um this was uh not achievable because once you put eof in memory you can manipulate it and you lose a lot of the benefits of eof being being self-contained so this is one of the barriers that's necessary for um for our code uh introspection Banning um I'm not convinced because you can only code introspect like at the barrier like when

you're going into euf but like once you're in you can't do introspection right but if we're keeping the barrier at the cing contract um that enables a lot of Rich features in that the systems only have to check at that point versus any crate that any contract could do and bringing in new dynamically generated code um that reduces a lot of the abilities of systems to say hey I only have these five contracts and you can also escape from the UF world with a with an with a call right yeah because you could delegate call and then Escape into it why already ban delegate call into Legacy Cod yeah you would need to normal call I guess

but wait how how do you escape UF um right now you can't because we ban delegate calls into Legacy code but you can escape with call and then create so you can manipulate EF code inside the EF contacts and then you can EXT call outside of it and then that that context will call create too right if you if that's a oh yeah yeah you make it as input data and you don't care who's creating uh that's really interesting yeah I don't know it doesn't

seem very different from the regular state where you have a god contract which can also deploy UF code but maybe um I need to think about it more okay so back to the topic of um how you call it the mode that would be the creation transaction top frame mode right yes yes

um it has some benefits like I guess the one is which we discuss just now which is the enabling creation transaction to run off of the salt based hashing scheme for the contract address um well it's like this this new idea it's it's it's I think it's much more powerful and maybe that's that's actually risk because um you don't need you you don't need to create anything you can just execute this code so it kind of works as a reach

transaction kind of off so yeah also consider this and maybe that's too much I mean but you still uh well it it maybe it's not very elegant but in that top frame would still ex be executing inside the well it no it be executing in some in some address but it's yeah in the address which you would normally be creating I don't know how to put it like the non and sender hash kind of address yes I think so yes uh but it won't be the address of created right um what I think we probably it's

worth to written down this somewh more for the next week and allow people to read it um but I don't think it's like clear clear card so maybe we just move on what we have currently um and and we can discuss it next week I believe shouldn't be so big deal uh to delay this one week because I have understanding like this is probably most of the people don't understand what I'm talking about anyway I can I can translate this into APR to the creation transaction EIP or

eof measp if that's helpful yeah yeah definitely um so that what I'm saying like let's let's written down this idea somehow and allow people to read it before we actually want to discuss it MH but just to be clear what would be the main motivation behind it would it be more the the hashing scheme or the simplifying effect of it um what are we after is there a simplifying effect well somehow it is so one is that you don't you can I think get away with uh you can get away with uh this split

between eof container and and this like call data that is going it's it's appended after so I think the the version the version that only have container may work but it's kind of we kind of circled back to like the original idea about this and this kind of breaks the tooling and stuff so yeah that's that's kind of I'm I don't know yeah it seems appendant data will work the same as the current proposal so you still yeah still appended and you still have to

split yeah but if you don't if you don't allow to have appended data appended call data I think it you can stay still make this work well maybe the same actually I don't know that's why I I kind of also need to have it written down so I can think about it um gotcha yeah one subtle potential simplification that I see is maybe that like top level container would be then always runtime runtime container for both like onchain containers and creation transaction yeah that's one and the other is like we

don't right now we specify what return contract does in two places which are kind of similar but different in some uh fine details how is it different the the the address hasing scheme is different uh the 63 64 I mean you know uh the obvious Parts but it's still like we repeat the spec just just the same thing um uh they also don't appear at first

glance like one is obviously better but uh this thing it basically allows eoas to run arbitrary code right so it's like way more powerful uh because like you can do things like have calls you can run eof you can have like multiple eof create invocations which I'm in favor of personally but I don't know if that like makes it like some political thing about a account abstraction true we don't want to yeah I prefer it because it's like way more

powerful I'm not sure true it's kind of the same what you can do with current Legacy creation transactions it's not exactly executing anything from EA because current address executing the code is not EA address but this uh fake created address not fake yeah actually I mean I think the main it's not quite Rich transaction but something more similar to Legacy creation transaction um yeah I I think the different comes from the fact that we do not allow for return or stop in an in it container if we allowed that then then but we don't allow in this new idea

because it's yes but then it is a runtime container right yeah if and also like not clear whether it it it doesn't deploy right after stop yeah but right now what what happens if you send a empty2 transaction with Legacy init code and then stop on in it yeah I think it deploys Mt code yeah Andre uh that's interesting right like what is the executing address of this uh new runtime container it will be hash of nons and add and sender address yeah it's

uh so you're not actually deploying code to that address though because like the code that you actually deploy with ef gr is going to be like deployed from that address to right yes yeah it's like double hashed yep plus whatever salt salt and uh hush of init code yes yes yes I mean I mean but that's not by Design it's just by being having been left out of of the idea I I I wrote down right it's not like we have like anyone has has pondered this if it's

right or not so if you if you have a cre creation transaction in Legacy and you stop it actually deploys and contract okay yeah yeah it's interesting right because then you end up with garbage addresses which are the intermediate things that actually call create what if you just remove those then we have like free account abstraction yeah actually yeah we then we'll need to do stop after you have

create and then it supposedly deploys this empty code Contra contract which is garbage I mean I mean we don't have to right it's we're designing but then it's like it's too much Divergence from Legacy you have no I don't know like you don't actually have to deploy oh you're breaking up chars I cannot understand Charles hello what I saying you don't actually

have to deploy code to that you can just from the yeah for E you mean right uh for the new for this scheme right like if you have returned then a contract just like literally it's like the same as calling a contract that returns data you just have return data the transaction yeah yeah yeah yeah yeah sort of that was my thinking but um so okay so maybe to move on to the next thing I will write down the pr I mentioned and I can also potentially write down two with

with both versions and we see how it firsts okay and back to the agenda which I have okay there it is um I presume that that was all for spec updates and now there was one one more is one more sorry go ahead um so there was this question about new status code returned from calls in case you call EA or empty account which is the requirement from solidity they want to issue an error in case you call a contract but there is no code at this

address and also like Minor Detail is that it only is required when nonempty uh return data is expected uh so for this case looks very this specific case they want to issue an error and there is no way to do it in case you like in current UF spec because in Legacy they do this using um X code hash or EXO size actually to check whether contract exists and they do this check before the call and fail if contract doesn't exist in where in EFX Cod size is banned so um they need some other way and like failing or like rather succeeding with

some special status code from the X calls would solve this that's uh what we agreed on at the interrup um yeah like the only unsolved question is which exactly steros code to use I guess well I think we we we have some proposal in terms of status codes how to how to solve it I think so we can write down um I think the question is more less do we actually want to fix this so that's kind of more philosophical aspect to this

like um yeah do you actually want to discover this information and we we we are I mean we had some discussions with solidity I'm not sure I I can't tell exactly how much they are really care about this probably some distinct but uh yeah I think so because it comes to account abstraction we're like we're kind of going into direction that we don't want to actually distinguish accounts with code and accounts without code because we want to kind of abstract this away so um I mean technically there's is this kind of I

think okay okay solution to this by extending returned codes from call and so we'll have two two codes for successful call and two codes for for unsuccessful calls so there's one more status go added to the to the to the this pack we currently have and it's kind of I think it's much more efficient that what what we had in Legacy but I think the the question is like who we actually wants to fix this we do it because it's like a common

mistake but um in EF like there's this whole point like you it's like the same like I said in the chat it's like the same as having an is way off code it's also a way of inspecting code and like the whole point is like you can't inspect anything about the account um so I think it's like fine actually to not have a separate status code so what what warning would would happen there or like like what's

the what would be the outcome of of of uh like why why is why is doing this right now I don't I don't really understand uh there's common con so uh in the ABI it's possible to like return to have no return data and there's also like contracts which can like not return data and um so you can have a call which succeeds and does stuff and it's because you call the contract but it doesn't return any data or you can like call an EA and like the code size check is like there to

help you distinguish the two cases but it's actually not it's not necessary yeah I I yeah I don't get why why you would want to distinguish between those two cases well like if there's no code then no execution happened but EDM call returned success yeah but you that's the whole point of eof and account instructions like you can't distinguish if like you call the contract which did nothing or you called an EA yes that's also kind of like how I see

it so in my opinion this should not be a thing if you want to if we want to ban C code in introspection then we should ban code uh should ban introspection and and not just like get it back into like the back door through toor so yeah like the current way is done because we have code introspection so we're like okay we might as well inspect the code and see if it's an EA or not or sorry see if there's code or not because like it could be the same

but like it doesn't actually it's like a minor safety Improvement like you can also of course call a contract which you know does nothing and then returns you know return data um so if you're going to like Maria said if you're going to ban code introspection is like one of the outcomes which is like you can't do this check anymore okay any other comments on on

this should we move on to testing updates now so uh testing updates uh we have Mario on the on the call hey yes UMO so yeah there are can you hear me yeah all right yeah so um I saw the message that we need to uh clear up some PRS um I'm doing this today so it's just a matter that uh um I haven't got the time to review but I will do this today um I will go over the pr the PRS and if anything is necessary I will

just try to repase and fix and merage uh get it mer as soon as possible um yeah awesome thank you there's there was another comment on the on the tracker I think um and I saw the response that it's taking too much time and I agree it's maybe maybe too much uh overhead um I really like the suggestion of just using the existing documentation and and I see the point that it's uh maybe a little bit um it requires for us to copy more information from the from the actual uh test functions and I think that's doable so what we could do is um I think we can improve the doct strings

in the testing functions and rely only on that for the description of the implemented uh test cases um the main reason I I I pushed for the tracker was just to make sure that uh the unimplemented the not yet implemented uh test cases were not left out of implementation that's the only reason what I why I wanted for us to keep a Tracker but I am open to a discussion if you think that this is still too much um yeah too much too much overhead I I think we can discuss other options yeah I think it's fine to continue what we agreed with this single

uh tracker file for now um just like wonder how how it will play in practice because it's kind of like the the the central conflict conflict Point probably for many prequest I think we can we can like continue as we as we discussed and see if the like how big the issue is so I sounds yeah let's let's let's move on for now what I had what what the idea was more less um that if the if the generated documentation is good enough then instead of adding new instead of adding new kind of entries to this to

this file you can instead of add like test placeholders in Python so I don't know how to exactly do it if you need to Define like empty test or something so then it will be pulled by this uh this this documentation generator and you can brow kind of the same information uh but so like then if you need to add this test case you just go to this place holder and just F the the body of this test somehow like that so like placeholder would be just like the like the function with the the name and the description potentially so the description also goes to this so

it's kind of the same work more Les you just add some like piece of like some number of lines for test case you want to have but it's it's already has it's place in the source code so you don't need to kind of map this file to the source code and makes sure it's consistent and so on but I think it's might be too much to to I mean we can work on this feature maybe in parallel but I I wouldn't wait for it and like try to now spec out the this this this kind of upgrade uh so I think we should continue as we as we doing uh but that's that's the idea yeah that's a very good idea I I like it um

so I think there should be some modifications to the current script that we use to fill the documentation and what we can do is maybe if the body is missing of the of the function we can also add the um ex no no not xale but skip so pus has this marker that is basically just skip this test case and when we find this we might add something into the documentation like a i either warning or something that to to signal that the test case is is thought of but not yet implemented H but yeah sounds sounds good let me let me explore that idea and see how it plays out uh in parallel okay yeah sounds great

awesome right so this is the plan for the trucker do we have any other testing updates or U discussion topics on the testing um field uh yeah I want to bring up one topic so we discussed this uh briefly at interrup so we'll probably want to change the format for validation test a bit because so these containers that we validate then can be then can be different kind there are like init containers random containers and some containers can be both of these uh there are like different validation rules and currently it's kind of confusing what validation tests are actually validating which rules and yeah to make it more

explicit uh we would want probably to add some new field for each test case for the container kind which is like provided in this case um so I plan to try this first in ev1 unit tests because they have similar structure and after that I'll probably open an issue or PR in execution spec tests and yeah but then we'll have to change all existing tests I guess but probably not very difficult because there are not many yet yeah yeah like that's like this moment

idea I think it's might be enough to have like test definition but actually validate like both every case in in two different modes and we can record the result for for every case so so it's kind of you don't have to actually specify in the test definition you expect this mode you just execute this in both and record both both results some like that but we can talk later about this each contract will have to have a return or a well I guess it can only have a Reverb that's kind of a weird case but it'll have to have a return or a stop or a return contract at the top

level so it has to be one mode so running two executions of it feels like wasted Cycles when we know in advance which one it should be maybe you don't know which one it should be maybe you want to validate it in both in nit code and run mode and only in the corner case it only ever reverse would that come to where both of them might be valid you wouldn't know um in an operating mainnet system you're going to know it's in a nit code mode or in runtime mode because you only get it in a nit code mode at the create transaction and you get in runtime mode when you when you pull it off the tree you know when you're executing and validating it which mode it is you never don't

know okay I understand but I I don't think it's like super heavy in terms of CPU time it's also helpful information because you like kind of double the number of tests like all clients should return the same validation result for both runtime and N code mode for each um code sample but unless it's a contract that only sends a reverse half of those cases are always going to be invalid by rule which is like yeah and I'm saying

that's like a good thing because you're like doubling the amount of things you test I think it's wasted Cycles but I'm not going to die on this hell I'm not testing anything so it's just my opinion um then you have this uh verification of the two different modes already implemented yes um I know a front whether it's in runtime or nit code mode and then when you go into the subc Container validation you'll know whether it's in a nit code mode because you're calling it with eof create or if it's going to be in runtime mode because

you're calling it with return contract so once you know the top level one you know the state of all the ones below and it only affects um which um op codes of those three you can return in those so it's mostly the same validation just in those case you need to refer to the mode and you can do this linearly um the validation um you do the top container and then if a subc container has the wrong mode you would detect it there because you'd have a a return contract in a runtime code and that's what the error would be um so you don't have to do it in anything other than straightforward reading rendition of it the error code gets kind of wonky but that's okay I think we also have it right yeah we

have it in the pr isn't the pr just refactoring what we have no we Implement yeah we implement this validation um but now I want to do some refactoring to make this different modes of validation more explicit okay so yeah I had one one one more comment so uh we released this uh execution Spectre fixures I think that was mentioned a week ago um but I kind of mostly talking to marus um because Don

confirmed we like ivm1 and and Bessel agree on this um and it it has like set of e validation tests I don't know how big the set is but I think the promise of execution spec test is that it's a bit more clear what uh what's the expected outcome is like what the test actually tests and so on so I I wonder if you mariio has has used that because you said you need to check the test uh with your new validation implementation and uh maybe that's that's a better static

point so that's they wanted to check on this yeah so I implemented the the new validation yesterday and today and I started testing it with a like we have 16 test cases in within gu um inherited from some really really old version and three of them still fail um so I need to make them pass first before I can think about okay um any other test cases okay that's fine yeah but if in case this like a execution spec test for

we have that psilon and we just publish the def pictures in case someone needs to I would keep it in mind thanks okay um we are one minute P time uh Charles can we schedule the EIP 663 discussion for the next the question you have the next call yeah I was going to bring it up um on Discord but um I figured probably here might as well okay how do you

preper but just the overview is like I want wonder if like allocating that many registers possibly hurts um compilation and if this have been considered okay then any closing notes or should we wrap up okay then uh thank you very much everyone thank you and then see you next week at the usual hour thank you bye bye bye thank you