EOF Implementers Call #54

Transcript

all right I'd like to welcome everyone to VF Implement call number 54 is the 24th of July 2024 um right now our agenda is uh mostly standard we have client updates um compiler updates couple open questions on spec updates what should we do about detecting contracts um then uh probably longer talk on testing updates um and fuzzing will be part of that and then finally another uh item if we have time is to talk about Devcon talks their Doom next week um proposals and I want to give us an opportunity to collaborate if we want to set some things up for it or if we just want to individually submit to it it's up to

us um so the first topic is uh client updates um Peter do you want to talk about evm 1 and Aragon 3 real quick uh as for evm one I think we are up to spec there was one one back pick on on the way by Pavo and and that's it I guess Andre can you correct me I was out for part of the week so I'm not sure yeah nothing else we all the spec is implemented yep okay um nether M uh updates uh yeah the spec is implemented all Test

passing cool now the phone part happens um cool uh dragon R um uh we had one buug we didn't increment non if the validation fails that's fixed and I am making uh basically finishing the pr that takes into account if the bite code it takes into into C uh container type and with that we finish off the validation tests okay um I'll go for Basu um we had one bug with ext code stuff in Legacy uh we

needed a we were not applying it to older um Forks properly so we got that fixed and um it's not a you know it's because the rules there's nothing you could do with it it's more of a defense and depth fix but that was something that Guido found in his fuzzzy work um so that was that was a good find there um JavaScript ejs anyone from eels anyone from gu I have a PR out to gu um they had the same issue we had with exd call ordering

I'll p Mar again and try and get that merg into his his code um they also still have that bug also in Reverse jumpy based on the last time I check their code um were there any clients I missed okay compilers I'm not seeing any of our compiler people on the call I'm not seeing Daniel or Charles any compiler updates any up Ates on the uh solidity PC okay so moving on um spec updates we still have an open question about how

we're going to solve the contract detection issue this is something um solidity uh pointed out to us when we first did the PC um as far as checking to see if a contract exists before doing a call that's something solidity does as a user experience feature but also more importantly it impacts um you P 721 where they have specific uh protocols in their safe transfer for mechanism that depends on being able to detect if a contract is an EA EA or not and they detect that by the size of the code um so there were two options that we discussed one was to reuse EXT code size and morph that into is contract op

code and the other one is extending call values from EXT call and there may have been a third one that I forgot about um yeah there was passing the flocks into the XT call oh uh passing Flags into the call or doing a check flag on the on the output corre okay um if we're going to fix this in 1.0 we probably need to address this sooner rather than later especially if it's going to be a return code change uh Ben doesn't ex code size work anyway because it's not zero

bit it's like two bytes it's two bytes but we can't use the XT code side inside of the E contracts okay but it would work outside of yes yeah yes so uh eof smart contract wallet could accept it so is there any strong opinion as to what the best solution to this might be uh pow I see your off

mute and he's back on mute sorry I don't have you're good Lu changing changing seems the the common pattern for um Legacy is EXC C size and then is zero um but they' obviously have to be writing something different for your um so probably work pow is your mic

working yeah I believe it this uh but I I'm out of the context right now so I don't have anything to say this topic okay to me it seems like this contract kind of up code is the simple to agree on simplest to figure out the spe because the rest the other options are like too many options to choose from and none of them see my deal okay um looks like I didn't I thought I

submitted a PR possibly to 354 so if we do a spec change the question is which EIP should it be in um and I think it would be 3540 uh because that's where the other handling of EXT code is handled or do we create a new eipa to cover is contract or do we put it in the the callop code what are people's opinions on the best place for it just just before we do that um are we or how much are we concerned about the um the response of another op code being touched in a way I

mean does it count as a new OP code or not um yeah probably does Ian data copy doesn't so maybe it doesn't it's a new name um is ex code sized in it's not just it still runs doesn't it as of now it is the it's it's not allowed in EOS okay maybe we need to test that oh we should I think we have somewhere I'm not sure this head we do there is a band and permitted op Code

test that goes through every single op code yep huh my red hearing code isn't can't find it um but I mean that's also another point is that we could introduce this in in a future um fork and just add an OP code because adding op codes is still fine instead of the the but I mean it it could do exactly the same as it does in Legacy I returning two for Eos and returning the length for legacy and then normal still work turning the length goes against um

I mean it allows code introspection right but it doesn't allow introspection of e code only just the size also yeah only of Legacy sounds interesting however it is but then nobody need to change the pattern it would still work otherwise solidity might need to go or what are you doing here um you know you're checking code length um I need to convert this into an is contract

call yeah I think solidity is aware and they said they are okay with using whatever method his contract would work to like changing this code anyway for UF yeah but I mean if if users in solidity are doing their own you know they're using open Zepp or whatever to do contract length greater than zero and then solid why I have to reinterpret it no query and contract length is not available at all in the these of codes would not work isn't the current suggestion we're

talking about to to reenable EXO sites yeah and just return yeah okay yeah then I agree then that's the issue for to users and in general I not sure it's a great approach to have different semantic like in Legacy in UF and it' be the same it' be the same right right the target would be would yeah E versus Legacy would be different for the Target but not for the source of the call right right I like that's a subtle I didn't hadn't thought of that I really

like the subtlety of that because we have the same op code between Legacy and eof because what we're concerned about for code introspection is introspecting into eof code and we could View and this also opens up um using other Legacy contracts as data contracts um does you know in a future version of eof we could unban EXT code copy and EXT code hash but I think we start with just EXT code size and keep it the same behavior so that eof comes across as two and is otherwise a distinguishable from a link two contract that's not eof so what we don't have is an eof detector which I don't think there's a valid use case for right now right we would have it with

the ex ex has but we don't need it I guess do we in the previous call we talked about the delegate call uh restriction that I was proposing to lift and a proposed to keep the Restriction but add a way to detect e again I still prefer just lifting the Restriction but that one use case for adding UF detection I mean we would leave a lift code hat because the code hash is consistent and we wouldn't have to open

up the door of copying on contract code that's true I mean that still doesn't might not count as code inst introspection you can just check the hash on the other hand lifting the restriction delegate call seems like opening up a very easy path to working around code int introspection in general because you can delegate call and there call gas call Copy code copy or whatever yeah and you can just to do code copy of a legacy contract you just call a jumper contract and have code copy there

sry again I think so so the ban of these three codes is very easy to circumvent you just have another contract that takes one argument of the stack executes it and returns it it's super easy to circumvent with with Legacy in [Music] place is that an argument for enabling these theel codes in E context kind of is because it's not I think what's different between this and and the delegate call in self-destruct is we're not modifying account State and I think

that was the big issue with self-destruct is we were allowing non eoff code to change things on the account State um EXT copy EXT size and EXT hash uh just provide data they don't change the state of the account like a pay op code or um a create op code and really self-destruct was the only effective one to like remove code and that's since been removed but as a category I could see future account changes uh being proposed and I honestly think there are times where we might want just eof to have access to those as well so maybe we might need a ban delegate call into eof I don't know or we need to check on the operation that

we're working on an account that has the code but that's I think that's a bridge we can cross when we get there um with the account changes um but just Banning a a value read op code is Trivial to circumvent can you say that again about uh the delegate call thing So currently there's a restriction in One Direction but not in the other direction you were you were just making an argument for Banning it in both right right so we we're not there right now but if there was a feature in eof that allowed the eof account to be manipulated in some way like set a um

set a 7702 delegate or unset it and it only had it in eof then Legacy would just delegate calling eof to get at it and do that call um so you know eof only things a modifi account kind of don't matter because you can with delegate call into an eof and the thing is We Can't Ban delegate calls in eof because that's going to remove a lot of utility for things like Unis swap so I'm I'm I'm hypothesizing on features that don't exist yet and it's kind of an argument for why those features should not exist if we allow account changes it should be available to Legacy and um eof but if we're trying to keep things out of the world get rid of these account changes

like self-destruct then we can't let eof call Legacy because that would bring those back into the eof accounts and was um self-destruct and the sweep oper the basically the sweep operation U of of the balance of the ether is what remains in self-destruct that's something that we're trying to get rid of um as a whole and the getting rid of the deleting the storage in the code um was a compromise to make veral work but it still has some side effects that we're still trying to keep from entering eof if we can that there are no features that manipulate accounts that are eof only

and I don't think there will be is pay really Legacy only is what P the the new s pay is right now Legacy only yes but I mean is it isn't it are you not able to get the same behavior on eof not right now you can't do an unconditional sweep ball balance at the end of the transaction um and that's it's a yeah because uh self-destruct interact strangely with um

the call stack as well um so pay is not really self struct is not really pay um there're is a legit pay proposal that has different semantics I would call it the new self-destruct the 6 self-destruct the 6780 self-destruct is not an e all right so were there any arguments against removing the Bayon on EXT code operation what's the strongest arguments

we have against it you mean all three or just the two ones that we are which yeah there's there there's two options there's all three and there's just size and size and hash right oh yeah size size size and hash size hash and code copy right and size is needed for the solidity case the NF nft or what I think that was erc721 yeah anyone that tries to distinguish between whether they're setting to uh an EA or a smart contract and then HH is needed for what front is U the case um making the case for which

is to make it easier to ex delegate call without like more predictable result right more or less yes but we have no case for copy and it's it's the most one because it actually allows you to read the code right and then I don't know it is I mean that's that's the only one that's actually int introspects code right correct because the hash is fixed code yeah I think I see an argument against it is that if if there is the chance to remove

code introspection IE code copy in the future through some kind of migrational Legacy contracts this would make it a lot harder so one I I would be I would before at this stage just uh code length and have it do what it does at the moment mainly because there's so much code in the wild that does that check for is contract and um rather than trying to get either change in user Behavior or uh solidity to have to interpret what the user is

trying to do and change the op code that it puts out it' be easier just to support Cod um I put a I put a I put a link to open checks and Ben what's your opinion on code hash um I it's maybe not harmful nobody's nobody's doing anything interesting with kach really in terms of um be you know beyond checking whether it's an empty hash or something else you're not doing weird math

on because code hash would be useful we could check empty hash we could check um EF z00 and also if well you can always Escape out to another contract to do the code copy for you um but you could use the hash to prove that you have contract data in memory and extract data from that um kind of as a proof but that's kind of a roundabout thing yeah I mean I don't I don't think it's harmful it's just reading a property of the accounts mon bik balance or whatever okay so I'm not hearing strong objections to code size kind of lukewarm

on code hash anyone else got a stronger opinion on either way on that size is going to work with Legacy so it will return real Legacy size inside yes yeah just keep it simple yeah so the the two two upcodes are behav unchanged yeah literally we just leave the Restriction of the validation State and I think the rest is just should work at least speaking for even one one liner so one liner for Basu plus test Code test code yes I think I think if

you reintroduce things like code copy X code copy and things then it you know you're starting to they're starting to box ourselves in in terms of the future but I don't see any harm with length or hash so how about we start just just with hash and we can think longer about not hash just start with size and we can think longer with hash we see what the reaction to this is but we can always also bring back hash or another detect EA in a future um future fork

okay so let's let's go on that for now my I screen so I think the conclusion there all

right next item on the list um it's probably a testing update in 30 minutes it's probably time move into testing um Mario got any info on testing anything you want to lead with or should we just go into the other questions we have okay PA sounds like Mario's muted go ahead pal yeah um uh I did some fing recently and it's still in progress but I was able to integrate evm

one and and R evm into into your father and and uh we starting reporting some is that has been found what fuzzing framework are you using and what do other clients need to do to participate yeah I'm using I'm using lip F so it's like coverage based instrumentation uh for like native coach mostly um so I was able to to get coverage from last I think there's a way to get it from from go as well so I plan to to start with this three three implementations and for the rest we'll see um like the basic the basic thing is

to just export uh CC kind of function from your implementation even if that's without coverage that that's also useful and we can think how to enable coverage later on okay pal so mostly something yeah something like static Library when you have single single entry point I can call and that will validate yourf and I think it's enough to just reports true or false for now so that's that's the the basic the basic we can

start with okay um Ben and Aon is um is producing a static Library something that net can do in Linux uh yes I think so although need to look into a bit more okay I think there's a way in Java through gr VM I found a post that someone did it um as long as we're not testing kzg or BLS um and speed performance speed is not a concern um we

should be fine there um gra VM is not the fastest implementation out there okay that that also like even even before that um we can export the all all the all the test cases found so far into Json and then you can just run run it from their um so I think so what I wanted to say nothing is really needed right now but in like next one week or two I might ask some some people from different teams about advice how to integrate I if that's

possible um an unrelated approach I was thinking about for fuzzing is if teams expose T and server or if we fuzzed it through the engine API but the engine api's got a lot of overhead um or if everyone had e simulate which again has overhead that not everyone implements but a standard Json API where if you implement one of the standard Json apis we can fuzz you um that's you know one approach that would make it easier for everyone to come in the problem with that approach is you can't use coverage to guide the fuzzer you would need to have the mutations come through separate means uh Mario you said your mic is working do

you have any comments you want to add hey thanks sorry for the U issues um not not that many um I've been working mainly on other uh PRS um but yeah I agree that we have to do something about fussing we have been trying to implement went some kind of fussing into East um but nothing concrete yet um I I I think I think I think the way to go right now as Mario suggested in our deps is uh F CBM for the short term but in the long term I would like to for this

to be also included in in East um but yeah I I don't have any solution right now about about fing yet uh but we will start to explore it at least in the following couple of weeks uh to see to see if how we we can Implement that in East um yep um where's what's the does anyone have the I looked at guidos fuzzer it's I want to look at fuzz evm before we go down guidos too much umo's got some good hits vice versa what's the GitHub link to fuzzy VM give me a second I will get

it f ZZ y VM that's what it is there it is I Shar it in in the in the chat yeah it's in marius's repo um because when you fuzz e you can mute you can mutate an OP code but that might imply changes in the header otherwise it'll fail validation so we would need to get some more uh changes to the mutation step but this gives us something to work with so the the advantage of East is that it right now it calculates automatically everything that you need for the ha to work uh so the max stack

height and all that stuff I think um it it could be really easy for us to just Implement sometime of fing but um it's it's it's going to it's going to be a little bit a little bit of wait until we finally got it working uh the advantage of fbm at the moment is that it already has the the strategies and everything set up so it's missing some pieces still in my opinion this fuzzy v um a guided fuzzer or is it just strictly a random fuzzer based on the strategies the mutation strategies I don't think it's got that but I I I think Mario should have a better answer

okay because yeah because if we can get into East um then we have a standard interface where everything not guided okay that's actually good to know because that was my big panic when I was looking at these fuzzers I like Java's got some it interacts with it tracing apis and that's how it gets it guided in BM um but other I don't know if other languages have live um coverage of their stats so we need to do multiprocess which is another complication but if it's not guided and it's just doing um intelligent changes I think moving something like this into East um opens up that all everyone that can fill tests can be fuzzed and even the ones that can't fill tests we could still throw

the fixtures at them as they're generated let me let me take a look a deeper look into fbm this week and to see how what we can bring into the East World East world uh from from it um I will have a better better context and better opinion uh next UF call okay and the nice thing is that this is not

only beneficial to youf I think this is an important part of testing that needs to be into into East uh for yeah for basically every single EIP that we we test for yeah and what I like about putting in the East is it's it's a common setup I got fuzzy working once with go evm lab and it was not a simple setup and I'm not even sure I had it set up right in the documentation um if if if you understand the tools the documentation is probably sufficient but I don't understand the tools so that's probably the problem there is I don't fully understand those two tools okay um goof gas usage of op codes um we need

to get a long-term strategy um one of the things I mentioned on Discord is and I'll I'll probably go ahead and write up a demo of this this week if no one's got it on their plate um but uh a mutation where we take a legacy call and we call eof three different times with the change without the change and with the change so we can get warm cold and non-existent and that should give us a baseline to figure out what the gas cost of the op code is um and that way we can make more generic tests out of it but I would want to mock it up and try it out first um Peter I see you came off mute do you have anything to add to this or comments yeah I was I was thinking about this um I'm

not sure if you share my uh reservations with this I I guess this would work it's just it sounds more like a long-term strategy than shortterm as you said I wonder what the shortterm strategy could be just just to get the for example EXT call tests um in shape in in East so the really short-term strategy is to not test it in East to test it in the fixtures and just make sure we all agree but that's going to provide really bad metrics when we get it wrong because we have no idea what we're getting wrong because there's no explicitly saying you

got this wrong yeah I mean there's there's the the short-term strategy which is used in M Copy memory expansion test at least which is just calculate calculate the gas expected gas cost of a you know a particular call by hand and and just assert on that this is kind of dump and maybe inelegant but the downside yeah the downside um if we don't calculate it independent of an implementation is we might all collectively get it wrong um and we might change it to the wrong

implementation to try and align with other implementations versus coding in the East we have the correct answer independent of them so that's yeah we we do need a long-term solution I mean the advantage of pre-calculating my hand right yep CU that it's like a another point of reference when it is not calculated by any evm implementation it's just calculated by hand and gas costs aren't like you know hashes which you're not calculating that by hand right right I mean the the downside of the manual approach is you know

uh we can get we can get the manual calculation wrong but have the right answer right because you have a lump you have many instructions involved and you just compare the end results and you know you might confuse a I don't know gas cost of a push with something that should cost the same and no have the right sum and and but the wrong pieces yeah and it's ugly and and with the with using the gas op codes my concerns are it's I mean it it also doesn't I I think it doesn't help with out of gas uh

testing right out of gas OG yeah except charging the right amount you should also test if if that amount is not supplied and you out of gas at the right moment and sort of the let's called the M Copy test style one seems to cover both maybe not ideally but somewhat because in in this in this style you just calculate the gas and then you have one case where you supply that amount of gas and the other case when you just subtract one and the subtract one case should fail and also I mean what if I mean this

this may be hypothetical but what if we want to test evm implementations we do not which do not support non eoff code at all then making a long-term strategy using the gsop code might be risky right right that would involve an EST change though to run the three tests well figure out what the warm call is so I think M Copy is a manual calculation so if you always provide this manual Cal I mean it doesn't have to manual you have to only provide the formula or the function to get the gas

the gas cost um what we can do is maybe just come up with a decorator for testing um where you supply which up code is under test the formula or the function that is used to calculate the gas and then it automatically generates the this test cases that in in the same fashion as M Copy does right now because we we already have free free op codes tested like that which is my shameful addition which is return uh something else I return that copy and also data copy just just copy the same like pun intended nonintended they copy the same approach oh um we already are at the

spot with we could make like a mini framework for these kind of tests but it's an investment yeah yeah of course I understand um Let me let me revisit those tests um just to get an idea how we can just make a decorator to make it super easy for for for for anyone to just come with the formula and the G and the and the out code they want to test and then it should automatically produce all the test cases and the advantage of making this a decorator is that if in the future we think of a new test case that applies to every single of these patterns we just have to modify The Decorator and The Decorator will

automatically update every single test case where this is applied and we get we will get new test cases for free um yeah but yeah I I I need I need to take a look just to to see how we can design it yeah yeah just just remember about the quirks in the EXT Co G calculation which might or might not be able to be put into this kind of a decorator approach because then for EXT call the you have like this how do you call it um the more gas you supply to a function the more it changes the the way it's

distributed for the Callum you need to supply this minimum retain paint gas and also the minimum C gas and and then you know this this is this crazy formulas to calculate the expected gas so I mean just just we need to be wary of this yeah of course so it needs to be very configurable so um I mean the base case would be something like M Copy yeah but then if you if you try to to test something more complex that has different like um uh levels of of of of gas when when when you go out of gas and something like that um you need to be able to configure

this also into The Decorator um it sounds complex but I I I would like to see if it's possible to to implement it um yep I I will reach out to you U uh if if I have questions about call Y yeah yeah please do I'm not sure about the long-term strategy though do we do we do this gas harness or or Trace tasting which also popped up so if you have any thoughts on that um you can also um let us know yeah okay

thanks all right I think that's uh probably need a time box the fuzzing if we want to get to our last subject um which is the subject of Devcon talks um do we want to collaborate who's submitting what spaces do we want to make sure it's covered um I submitted one talk with a future of eof talking about capabilities and some of the extravagant things that might be added that are enabled by the container um but I haven't submitted any other talks and I want to hear what other people are submitting to make sure that we have the coverage and and people who are willing to go and willing to talk so make sure we get enough coverage for this uh Peter you came up mute briefly nope just gone on

mute okay so um who's planning to go to Devcon and take that long flight and even if you're not what talks do you think we need to have coverage for should we have an eof panel and if so who should we invite and who should moderate I mean I um I don't know if it's premature but

we're sort of thinking about the the way to structure the e related talks but I'm not really involved in this so maybe someone else can can speak me see there's Alex is not here yeah aan rais his hand um Dragon had bad luck with the VISA do you think you'll have better luck with the taii VISA uh should be easier uh to be honest about talks related to if um I didn't thought about

that a lot uh having like panels seems maybe it's the best option U yeah we should have few talks but having a panel additionally seems okay especially because the people don't know what T is they TI to one thing like it's performance and why we are doing 10% performance so there is a lot of confusion related to UF we need to somehow make it clearer in some way in form or form okay so would this be like a

history of the evm and how we got to eof would that be like the guide for that panel yeah that could be nice uh the the frame frame that we want to get is basically hey every change that you are making around thef are basically the minimal set that we have we cannot like remove things from it and we thought a lot what needs to be included and what needs to be added at this point of time

yeah or some version of that okay do anyone want to volunteer to be on a panel I would volunteer I could do do I need go okay I honestly think we should get Greg or Boris if Greg's going Greg's probably not going it's know Forest man is going um happy to uh with you Dan and try to look happy to work with you and try to add more people on the

panel uh but for that we may have to make an application for that would you be willing to make the application for the panel discussion or do you want us to take care of that I can take the panel application I just want to know who I should list should be on the panel who getting feedback on that um I think we should have someone from evm one um and the reason I feel that is because they've been one of the longer term um developers longer than me um as far as getting stuff working on the evf and they also have I think the biggest thing we can get from someone from Team EP Salon is um feedback on what happened during

ewm and how that informed where we got to but I'll I'll ping the ipsilon team separately on that are there any other I guess one question do we want to have it um do we want to have a skeptic on the panel and if so who and how should we handle it or should it just be a a history in a in a pro eof panel it's hard to plan at this point because that's will it still be in come November honestly I mean yes just more in

hopefully to dress the elephant in the room okay we can always ask can always ask Marius he was mostly like voicing out his opinion about UF right and that's so mariio is probably ask yeah and and this is like three months and a lot of thing can change in three months opinions right right it can be also Martin and because I think he had some also some criticism recently yeah Marius or

Martin okay because I do want to get you know the the the skeptical side on it but I also don't want it to turn into a 40-minute debate about the legitimacy of e so we'll need to make sure that whoever we get to moderate will will keep that in mind and that's the next question is who do we ask to moderate I mean maybe I moderate I don't know a journalist would be nice but I don't know which one okay um anything anyone wants to discuss before we end the meeting Tim would be interesting I will ask Tim he might be too busy but I think it's worth the ask um anything else that anyone wants to

talk about before we on the call all right um if you have any other comments uh the discord's always open feel free to ask anything uh thank you everyone for the time spent working on nof and coming on this call and we'll see everyone in the next meeting