EOF Implementers Call #58

Transcript

this is uh EF implementor call number 58 it is 18th of September um as far as agenda um some of the items that um I think we need to discuss are devet Readiness um tracing support which was uh mentioned last week two weeks ago as contract is contract EXT call return codes and probably finish up with a discussion about um the Petra split which they're going to make a decision about tomorrow and get people's opinions on it battery low um zad can you mute unless you're

talking thank you um so let's go ahead and start at the top of the agenda um client updates um I have a PR out for GU that brings them up to 100% on the um State tests and they've been at 100% for the validation tests there was a fuzzing finding that was fixed and is also part of that patch too for validation um Basu um there's one test that is failing in the test harness strictly is a test harness issue that's a zero link eof validation so there's no substan of breaks there um next on my list Ben Adams do you have anything for uh nether mind yeah we have a 19 test fail uh um mostly

in the container tests um every work how we're processing tests they're easier to work and run them individually okay um yeah I can take a look at that and see what what's still needing to be fixed there what what test is still broken then what what test are still failing um what are they uh mostly container combos um a lot of them are complaining about K section contains return contract I'm trying to

look into what the rules are yeah yeah that was um if you get stuck just ask for questions on the chat room um we've gone through that quite a bit so we're probably familiar with the breakages you're seeing and how in scenarios and how that might be fixed um ref uh dragon do you have any updates um nothing new basically yeah yeah you've been clear with the Frog based dat test for a while yeah I updated uh rme execution binary it will now transition if the

prag state test is basically given it will activate Prague UF okay that's good yeah so I have I haven't run a a bulk execution of all the tests in a while so I should probably do that tomorrow or maybe today while I'm up at the conference uh just a note just a note on Prague so we're running as if we're on Prague but we haven't had the uh prag Fork merged yeah so so that's a discussion for one of the other items we're going to discuss later whether it's going to be Prague or Prague 2 or Osaka um but whatever that one is whatever we decide

tomorrow on ACD I think we should get all our stuff set to work on um that's that's one of the hot discussions um maybe we could just have that discussion now let me get um ipsilon anything on evm one no I I don't think so okay and do we have anyone from I don't see anyone from Death do we see anyone from um ethereum JS or Aragon NOP okay so um where my agenda where my cop of the agenda go so I guess the question should be

devnet Readiness um do we feel that we're going to be able to make a devnet in two weeks time I think we're almost there the only question that I see is whether it's going to be pectra Osaka or Petra 2 anyone so let's go ahead and open the floor for the discussion on what people think about the um the proposed Petra split um feel free to share opinions you know what whatever your thoughts about it are from red side we would prefer it's

if it is only one fork but we don't mind if it is split into for the naming to be honest it's mostly like bike shedding and in the end it wouldn't matter a lot maybe call it Osaka because that's how we call the next Fork I don't think other the Gil mod there is nobody else opposing to it okay um would would moving it out and separating eof from the other prod features cause problems for any of the implementations how intertwined is this with your implementations um it isn't at the

moment but it probably will in a week I'm sorry could you repeat that I had some noise in my background um it isn't at the moment but it probably will be in a week or two when act merges to uh okay would it cause undo problems or is it something that can be managed I think it can be managed um D the issu is like I sense horrible merge comp okay on Aran s we already have UF merged so there is only one place where we need to enable UF and that's it in um

transaction creation Crea transaction yeah that's the only place where you can enable it okay so that's good info to be aware of going into tomorrow so it won't won't ruin our day but there is preference to go as one but not stop the split preference I I don't have a problem what I mean is the complexity will occur because we will be on top of chor if you see what I me um rather than so it wouldn't matter whether we split or don't split either way okay because I assume EOS is not suddenly going to jump in in front of the rest of

patri no not yet I would be surprised if that happens 7702 kind of jumped the line but hey whatever okay um with with regards to splitting it I I'd be okay with that but I wouldn't want pure to to follow the normal Cadence of like you know then be a year after i' want it to come in fairly soon there soon what's your ideal of fairly soon I I don't know um I how long the devet testing process is but hopefully under under six months if not

sooner okay but entirely yeah I don't know how long how long it goes from De Dev not Zer to live right and that that aligns with my expectation I was thinking the number I was thinking was one and two quarters which is six months um just want to say idea main basic idea for the split is to speed up the process so yes you can yeah that's the main reason VI splitting so even if the splitting is going to prolong the hard Forks I'm not sure if there what's the

benefit of the split maybe it's easier to test but well I mean Forks like to grow so that's that's the risk um yeah where go ahead bring it as soon as bring it in as soon as possible because we're all kind of ready as it were yeah because there's there's also pressure to bring um the SCP 256 R1 curve there is pressure to repic data uh there's pressure to uncouple The Blob counts but that could probably be tied up with a p dash shipment there's there's a lot of things that people a lot of urgent needs starting to develop

for some of these so if we do split it I do think it will grow but the trick is to keep it under control okay anything else we want to say about the split before we move on to the other parts of the agenda Ben you're off mute do you have something uh no okay um if you think of something drop it in chat and we can discuss it near the end um eels eels is here ah we didn't go through them in the client um how's the how are you going with your implementation yeah so we basically uh

we just uh had all the eips implemented we're passing all the tests and all the latest test so yeah we're good actually the pr is still under review though that's the only caveat but uh in terms of coverage we've we've got everything the EF tests and the blockchain tests awesome um wait a couple days before you press merge oh yeah absolutely um next on the agenda we've done client updates um how about compilers uh Charles you have anything um that's a really good

question um I don't think we have anything right now I've been on way for a little while so I'm still getting back up to speed okay e all right and the next

is spec updates so we have three items that I need to discuss the first one um is tracing how's everyone's has anybody been working on their tracing stuff as part of this yet okay so um one of the testing features we're going to need whether it's before or after UF shifts is we're going to need to get high quality uh fuzz testing and um one of the things that I think is important to get this high quality fuzz testing is we need to have good tracing I think most of the clients have tracing

but I think there's a few fields that need to be added to make sure that we get um measure if we're having any fuzz differences and the most valuable fuzzing findings we've had have not been ones where the final answer is correct or incorrect it's where we discover differences within as we get to there um that ultimately wind up being the same but in the middle we find problems when we run the fuzzer and some of those can be um rebuilt into viable exploits um we've seen that historically it's been a few years since we found a good one um that could work that way but those are the sort of things we're finding with fuzzing and why we do um Trace level fuzzing so as far as our fuzzing for eof I have an EIP here

um number 7756 we I'm proposing some changes to the existing standard tracing and that's basically adding a few Fields um adding the section field adding the immediate field um and adding the function depth I think that's all that I have added think I added explained in the rationale immediate section of function function dep dep and also clarifying the PC um should be zero within the code section when it's present not like against the um zero index of the container or the zero index of all of the code sections um now that particular issue is going to have some interaction with um

veral um so that's where you know having zero against container might be useful uh but that is something that we could you know right now that the standing is say zero against code section but this uh is currently in um draft State um where's the Header information draft so yeah this is in draft so anyone has any comments about this um feel free to chime in this is far from Frozen um Basu does have it implemented but I'm more than happy to adjust it if we think we have uh if we need think we need to change it any comments

um nethermind do you have uh tracing implementation as part of your um state test and block tests uh yes we do um not we haven't made any changes for okay and I know ref has it because I started the patch that got cleaned up and finally submitted um G has it to does eels have tracing I guess is a good question for Guru yeah eels does have tracing but we just need to adapt these extra Fields uh to be able to support everything with the E so we've not done that cool and Mario mentioned that

tracing might be useful for TN um I think there's hacky ways to go at it but I think yeah we should probably integrate it in a TM um have like a designated output because this is where the real value comes in is also testing and the fuzzing solutions I've seen tend to use uh State tests and block tests as their basis po yeah are are you going to to actually apply it to any funding yet or it's uh I think we can we can get something in this shape um if that unblocks some testing I think

that's good idea I I don't specifically like the the section but uh it's not difficult to to implement it just kind of feels inefficient in a way that we don't really split execution into sections can you elaborate on that um yeah if you if you consider like code sections they're just because are just adjusted to each other you can pretend like the all code sections is like one executable code and The Interpreter just goes over that because validation handles of all

the like nasty cases so yeah if You' consider like how how ev1 thinks where it is currently in the code it just knows the kind of um code pointer that is relative to the the first code section or like the beginning of the first Cod section and so on so like to to actually compute what the section it is I would need to have some kind of look up table so it's not complicated it just seems if you want to produce that all the time unless I will just yeah maybe I'll just remember that somewhere okay I need to

think about it but uh okay because the reason I put that in um is we need to be able to validate that call L and jump FS are appropriately collocated now if everyone was not using sections and zero based off of something um we would still get the same signal and everyone would agree because this is designed for differential testing so yeah so if we were all zero based off of the code index or the container index and I you know if we're going to zero base off of something other than your code section I would think we might want to do container index uh because that's really going to pay off dividends for veral yeah I now when I started to think

about it think maybe it's not so bad okay um yeah I think we might try to to make a prototype thatou we have some we have some tracing like for basic M and it has been used in in this in this kind of fing we can try to set up um do you use go even lab for example I think we were integrated there and I guess we can try to kind of if you have Alternatives feel free to discuss them in The eth Magicians or in the Discord chat um I'm not locked into

this at all I'd rather have discussion and change it and have no discussion and no adoption all right so next is has code is contract um does anyone who's been paying attention to AA want to summarize that concern yeah I had give a quick summary uh so on Discord on the future EA Channel there's a

discussion uh where the account obstruction perspective has been uh described and also there's a response from uh from the proponents of H code uh instruction so best to go and read through that but I think as a quick summary is that the problem with AA is that with hcode or currently with a CO size um there's the pattern or anti- pattern that some contracts prevent nonoa accounts from participating in various forms and for various reasons and you the the existence of such patterns uh

with slow AA adoption this is the claim and and also on the other hand there's also the claim that the ERC 721 case could be better solved uh with the application of ERC 100 65 65 which is supports interface yeah so for the details refer to the disc discussion on the other hand there's uh I mean there's a counterargument that actually the AA adoption is down by something else namely the lack of adoption of smart contract signatures and also a counterargument that

the uh so to speak uh bad patterns would still um be possible even without has code so yeah I guess just just recommend to read through that discussion on Discord for details but I think uh there's no no conclusion yet it okay um kind of a meta discussion separate assuming that the AA thing doesn't the rail this EIP um where does this stand with the split

if this if petor were split in two could this be put into the first first release of e hard to say I think uh the main reason for having a separate EAP is just to uh discuss when to have it right and we have some preference for it not to be shipped in the fork where I mean until the split we were we didn't like the idea of shipping it in the fork where you ships um to be able to gather more insights or data and also not to um inflate the

scope now with the split I think I mean the sort of mixed feelings because uh the split is partly because of the scope uh being too large so so I don't know I guess we still one would like did not to be um coupled with the rest of the O it is it isn't very large change no I I mean we are kind of responding to the ACD uh complain that there's too many up codes and too much complexity and uh with that but I guess I I mean the

split changes uh the situation a bit okay in in general I would like to include it I would mainly because um it sort of makes some of the requirements the RC is impossible so therefore it would May resist adoption of [Music] mostly open Z because I don't want to

figure out how to spell Zeppelin here okay anything else that people want to say about has code um instead of I for RC 712 and 115 what was the example again uh erc721 and ERC 1155 uh two and one55 are there any other examples of this

pattern I think so I mean there's there's been complaints about the pattern that you um it's not generalizable but um yeah it's a where where where you sending it to is a smart contract then you call a function on it to see whether the smart contract understands um uh the type um so that you don't send nfts to Smart contracts will there'll be lost I mean are there any other examples Beyond these two erc's that have been

reported um no I haven't heard of any other requirements for differentiating between the two but that's you know has been pointed out because they have a particularly weird use case that smart contracts must be willing to accept the token via those apis and um in their absence um EAS um can accept them so if if we don't have that then you're in the risk of either a locking nfts and smart contracts that can't send them out or B not being able to share them with with um eoas I think there was um one for tokens but um the issue with that is people used them to do

um uh what you call it flash lenss in the callbacks and Flash they didn't really get catch on defi I mean I okay breaking defi but you know that's know probably not gonna fly anyway I have a dumb question which is um you always check if there's code to call like onc 721 received right but um if you just always call it then it'll just return nil data if

it's an EA and that's how you can kind of tell I think yeah but gas the gas op the gas optimizers will hate you the gas optimizers will hate you and um your fallback might mimic an eoa and then you might be stuck I think that's one of the claims of the U ERC 165 approach is that the uh that want to be common I guess I mean there's like a strong I think there's like actually consensus among like uh developers I've talked to that like ersc 721 and 1155 are like actually

badly designed so if we're talking about like new like we don't have to worry that like I don't think we have to worry that like new standards like this are going to be created I think the concern is only whether we can make erc721 things that are compatible with the existing standard and I think that um you I think if you call on ERC 72 un received and it rece returns nothing then you can revert or um sorry do what you would if it were an EA how' you phrase it provide the same

protections and um conformed modern practices well the the same protections like almost same I don't maybe same in practice but that's something that needs to be investigated maybe okay yeah there's like you can't tell if on ERC 72 un received is like implemented badly as then it doesn't return data or it returns bad the form data or if it's an EA um but I I don't know I kind of think that's actually

okay okay anything else about has code um I don't think we can go ahead the thing is like normally when you call onc72 received um you have to like check that the return value is actually valid anyways and if it returns um uh I need to think about this sorry yeah the problem is the EA is is not going not going to return anything and still is a valid recipient so it's it's indistinguishable from a contract which just has a nonreverting

FB function returns empty yeah and I think the people are like a big fan of right and how common outside of AA is that pattern where your fallback um returns a zero length string um your fallback should usually return nothing like um I don't know like any fallback I can think of actually doesn't return anything okay so I mean for the AA

recipients I guess the the the specific fix for that is that that such a a uh contract would support ERC 165 right and it would uh it would you know you would be able to discriminate such case so if you add 165 to the equation it actually makes the uh problematic contracts even less common right because you might have a nonreverting fallback function but still um do the right thing using rc6 165 that

correct um I don't think you can rely on contracts implementing rc65 well you you would you would I guess have to rely on um uh wait uh or [Laughter] maybe contracts can Implement like is contract it's a new standard sem my yeah what if we get anybody to implement

that is that the same as having the has code op code so that wouldn't work with existing AA accounts like smart like safe wallets so um and it would also fail for EA yep so I think um we should probably table this for two weeks the the split's going to give us more insight and hopefully we'll get some resolution on the AA concerns whether we should accept it or pass on it or and then intense and swab is like kind of on the other end of the

spectrum hello okay they muted I don't have host prefs but they muted so we're good um but yeah I don't I don't this but we might need to push the issue and make a stand in two weeks and think about it I think either way we roll it there's going to be people that are going to be unhappy with the decision so we just need to make the decision that's best and I don't think we can make it today last thing I have on my agenda um is to discuss exe call return codes this may be Jumping the Shark a

bit not Jumping the Shark jumping the gun a bit um but in the review of the GU uh patch um gu expressed concern about what type one and type two means um it started out from the uh concern that it doesn't map neatly into their implementation which in and of itself is not a bad thing but when you look at what returns of return code of one returns return code of two um it starts to not make sense and feel arbitrary so I was wondering if we want to consider if we split pectra um get some more logic behind what a one and a two means from an end user perspective and then back that into our implementations uh Peter you came off

mute yeah I was off mute actually for me the distinction is just one is uh there's still gas and two is all all the gas has been consumed that was I think we mentioned before so that's the idea but in practice there are all gas consumes it will come back as a one which the only tests that return a two um that we have in E ests and then I can figure out from the code um is if your return um if if your return data copy calling a legacy goes out of bounds

we fail um and then the other one wait we're talking about EXT Co return codes right yes yes and the other one is equally obscure um I mean to all G consume this or when when the call out of gases it calls invalid or there's a static uh static call violation St call that's the other one static call violation and there's a static call violation but the out of gas failures actually come back

as one um if I'm reading it correctly are you sure um we need to test test it then if that's what's going on I think I think it should be too I mean if it does out of gas within the col code right not out of gas out of gas during I don't know memory expansion should probably just unwind the stock some more I guess so it's irrelevant but yeah but I mean the out of gas in the col and uh statical violation and I think there was one more but I

cannot remember I think there is one where we check the stack I'm not exactly can can't remember what the call dep is also a um datas take overflow I guess com so originally it was supposed to be that the one is for for like user

reverts so reverts that are kind of programmed in in other contracts and anything else was supposed to be too uh but then someone realized that it breaks some I don't know break some like kind of you can extract more information from this yeah so we kind of downgraded some light failures also to one and I it's kind of the same I I think I reported this somewhere but maybe I didn't in the end but it's also kind of confusing to me it's it's

nothing that you can quickly explain to someone else what this vales mean and and I think it also is much less useful for for compilers because at least to my understanding at least solidity was was interested in having information that a call failure comes from like programmed in re and now we kind of broke this by mixing this together with something else and I I don't I'm not sure this is actually useful for

anyone and I think that encapsulates my concern and concern gu is Raising is what it was versus what it now has become is you can't explain it easily and my thought is unless you can explain it in a tweet um then we need to back up and reconsider what we have in which case if we if we don't change it to be more useful then the question is does it do we flip it back to to match like right

so this is something to think about over the next two weeks I don't think we can have a call for Action today um but this my my initial red hering proposal would be if there's no split we do nothing and if there's a split and eof winds up in the second half of the split um we redesign this um in something that can be expressed succinctly and cleanly and we go back and reimplement the return values but that's that's a red herring um you know just a prompt discussion okay any other thing that we want to

discuss on this call today umone uh delegate call versus allowing delegate call for legacy contact versus being able to determine if something was in EA contract because there's the the weird Gap where you could break proxies by proxying into a legacy cont I think this one is easier

to uh work around was at the conclusion that this can be better solved by just making a uh a check in the um upgrade logic where the the new Target is called with uh with called with this EXT EXT delegate call and if it um fails then it will uh reverse the upgrade yeah I forgot to ask Mario about testing before I opened up the floor Mario said in chat for testing on behind

on PR reviews and was offline but I'm restarting the reviews today um yes please please bear bear up with me um I will try to finish up as many reviews uh as I can today um if you have any anyone that is urgent just ping me and I will try to prioritize it yep okay and um yeah I think pretty full with getting Petra 3 devet up and running so that's it's understandable why you're a bit behind on that um cool any other testing updates I think just one comment from the 7702 testing that we've been having

the last couple of weeks um one of the most interesting things that we uh found is that uh many of the clients were not like handling the new transaction type like uh in the most adequate way so they were basically rejecting thate P transactions so I think um and this and this was tested using East test the it's a new command it's called execute I think we can do something similar for UF in the future um where we execute the um the EF in init containers in the transactions in a live Network or in the dev Nets and we can actually automate this before we get ready for you have uh

to be live on ad devet so I think we can catch a lot of issues this way because it actually interacts with the uh Json RPC so this will test uh Json RPC I mean youf uh contracts coming from the actual e RPC Json RPC uh endpoints um yeah this is just to just just to let you guys know that I I will probably work on um a convers converting the the current container validation tests into a transaction I already have a PR but it's not it's not ready to merch and also this will uh um this this same converted tests will be run using this new execute

command um so yeah I think that's that's the only points that I wanted to to share so I've worked on a previous project where a theorum equivalence was an issue and a test framework like this is awesome I think it's going to be great for the ZK systems that are doing their own native implementations you're going to run into strange things so this awesome okay um now that I hijacked the delegate called a legacy return to that um I think the summary was the there's workarounds for it and it's

called to Legacy just a nitpick for the notes yeah because if you can do a delegate call you can delegate call Legacy all you want you can't do that in you was was everything said about ex delegate before I I cut it off though was that the conclusion based on the silence yeah just keeping it on the on the agenda as a unresolved issue okay I'll go ahead and

see all right anything else that I forgotten we got through testing wonder if we should move testing up earlier in the uh discussion I think we should start with testing from now on uh Ben um join you were talking about that previously yes um Mr anything to discuss or do that um we found one bug in gu um but to get good fuzzing um all the validation

tests need to pass because the first thing the Corpus is filled with is with the existing test cases and they're going to be derivative around those test cases for a while so that's uh passing the reference test is I think a step one and then once there then we then we plug in fuzzing so yeah um as far as the API NE mind's ready to go U we just need to get the uh that last bit around containers because the fuzzing will find that pretty quick um is e set up to handle TX

fuzzing not not yet okay um that's one that would be valuable for fuzzing and also when we get to execution fuzzing that would be very valuable all right uh dragon one last bik shed before the end this is just the IP change uh what about renaming types section to something like St K in my personal opinion types was very confusing when I started reading it just wanted to see what other people think

about that what was the name you're saying stack stack iio maybe yeah okay any other back Shing requests or should we call a lid for the day I agree that types is confusing but maybe like um section spec or something

because it might not just be stack section info was it sure section info or section spec okay precisely should be code info but yeah either way it is better than types or maybe code info signature what signature I concern of signatures that

might get confused with crypto yeah I know but it is it is a better word sounds like we're in a blockchain industry yeah I was referring to this you know solidity signature kind of it's not the same thing but I don't know it's abused it's abused already so yeah it's overloaded it's an overloaded phrase but I think it is one of the better phrases okay saying we should sign the code before check the the signature on the Cod follow before there is a deep rabbit hole we

could do with custom header types and I think a cryptographic signature would be one of them header size okay sorry I was not suggesting a name I was I was it was just a followup to my question yeah yeah sorry okay all right thanks so if that's it any any other requests any other open floor items going once going twice like to thank everyone for

participating these open floor items are great um I love the conversation and that's a wave or is that a hand dragon bve all right all right see everyone tomorrow on acde ACDC