EOF Implementers Call #50

Transcript

like to welcome everyone to eof implementers call number 50 um um we got a regular meetings scheduled got client updates compiler updates spec updates testing updates and other items um if anyone else wants anything added to the agenda that's not on the agenda please mention it in chat so I can see it um so we can get to it at the appropriate time first we'll start with the client update uh Ahmed uh can you have any update for nethermind um yes not sure if Iman is here maybe not but he's currently we

started again working on uh refining our implementation and uh mostly uh the EIP related to the uh creation and uh if that's done I think we will be mostly aligned with what we what the what the spec is and possibly even join a devet uh once that is done yes okay cool I'm going to go ahead dev's a good thing let's talk about that act in other items um let's see Bob are you with a

client team or are you just listening if you're the client team speak up otherwise I will move on to I guess Bas alphabetically a first name that would be Basu um I just merged the um last we had issues with being equivalent with um the gas costing because um I basically needed to rewrite our gas costing for EXT call so um I merged that and now Basu and ev1 create identical traces when you filter them out to their um gas cost and most of the other critical items for the trace um I'm about to merge it into Maine into into ethereum main um it's going to activate on a fork named Prague EF for

mainnet uh not for main for like genesis files but for reference tests it still activates on the prag name so that's what we're going to go for unless we um until we had at least devet 2 in pectra um let's see next on the list would be Dragon w updates yeah uh uh I run the the test suit that we had and I didn't have prag updated there so I had some few few test failing that I fixed I still have test related to UF create that I need to fix that's mostly on the red side uh on VI are adding support for the inside the

hry because if the rvm is yeah supporting UF it can be easily included with the new solidity compiler so after the problems with e youf create uh are addressed inside rvm it's probably going to be just yeah it's going to pass inside Foundry it can be used well that's mostly yeah cool um evm one uh not many updates Fromm one side I think there was to merge this tweak that we disallow trated data in top L

containers but that mostly affects testing and I don't see anything else here we have still the init code mode validation now change uh in review in progress and that's it I think unless prob can something no I I don't remember anything else y cool um do we have anyone from guest on the call um anyone from Aragon ethereum Js

okay um any other clients I didn't name cool um next item is compiler updates uh Charles anything from Viper no sorry been uh really busy with the big release okay that's fine um do I have anyone from solidity on the call okay um the solidity proof of concept uh got a few Updates this last week um so this is from um Peters writing this or no it's not

Peter Rada yeah um yeah the big the big difference is um timing wise is also been added to some some of the information other than that it's pretty much the same information as last week um just got a better organization and answering more questions as they come up go ahead oh Victor are you muted um so that's that's uh any other compiler updates before we go into spec updates all right

so for spec updates we got three items um two clarifications a discussion on a nit code and also one that I forgot to put on the agenda that came up during testing I mentioned in chat has to do with the address during eof create um it's probably just going to be a spec clarification it's something you don't think about until you start getting devious tests ritten against your code um so the first proposed change is requiring Max init code uh during validation um Peter you want to lead the charge on that yeah we have I have pitched this on the previous call and I think it's we

got some agreement that this is okay but I just wanted to make sure that nobody has any objections before we merge this so I think P was on board and uh you d as well I think you have voice yeah that was a different different one but I don't know maybe you're um okay with this then also solidity set we had we had thoughts whether this limit would not impact solidity testing but it uh we confirmed that it would not um and I think also this popped up in the recent Discord uh discussion with Marius from get MH and I think this uh this PR link

was was mentioned there and he was like okay with this I I think u i I haven't heard any objections if there are any please let to know now otherwise can we assume that this is a goal yeah I mean we'll have to hammer out the exact Corner cases as we find them but in general one thing I would like is if we tracks Max and nit code as the as the size rather than a new constant or a doubling of Max and net code um because that's what's going to matter for the system for testing um I think we just need to have a flag where we take it off because as was mentioned on on on the Discord I think there's going to be

valuable need for testing things like validation with absurdly large containers to ensure that we're really linear for example a container with uh a thousand uh full code sections that contain nothing but call of to each other um and that would be like 64 gigs not 64 gigs 64 Megs we make sure that you know validates within the appropriate um gas schedule time so that that can be worked on later what do you mean linear in size or in some other aspect in me we get the gas that is charged when you create a contract and we want to

make sure that the time you know it grows per bite so we want to make sure that the gas per second it would take to validate it doesn't slow the system down so I guess we could say we want the time per bite to grow linearly rather than exponentially or parabolically but that would be just like oneoff test not integration exactly exactly that would be a oneoff test yeah well that can be accomplished with just three kingd the implementation I guess yeah so that's that's the only thing that would implement this Max code size but like like you mentioned it's oneof and doesn't need to be repeated regularly go um oh Barnabas has an update for clients

from Marius passing 231 232 validation tests haven't looked at State tests haven't can't make the call today okay so we got updates that's good numbers from G um Mario you raised your hand yeah so this uh extra large UF test uh do we want I I think we want this in state test right because in state test it would mess a lot of a lot of things um so do we want this on the on a Neo F dust uh fixture is that is that the idea so yeah I think that would be the right place to put it we will I mean we that would like make the test size really

large I almost wonderful you need to have a separate separate torture test that is not distributed as part of normal tests um where we keep the torture test so we just torture the implementations um maybe once or twice per Fork to make sure these extreme I mean this is an extreme measure because we could keep all the 48k tests to make sure everyone's in time um with just 48k things but when we're going beyond the scope of the limitations I don't know that we yeah I mean we want to make sure we we dismiss uh 4 megabyte test but a 64 megabyte test but do we want to put that in the test cases another options could be that we can uh request the client teams to add this as

a unit test right in each of the that that's another option because we can keep it out of the pictures it won't mess with the format um but they still get get get some kind of feedback from from this test yeah yeah I mean we can design it design the test and then just distribute it to the the Tims and make sure that they are adding it to some unit test somewhere in their code okay yeah we can design test and have the python spit out the test that yeah that we can do that okay so yeah so we just need to get this

spec up where does this go 3540 yeah yes yes like the general code validation goes sorry the general container validation goes into 3540 so no yeah 40 okay the that has two sections one has for General eof and the other is for General eof V1 so it's it's like an editorial decision whether where do we actually put it I think ez1 is better but it's just a matter of

days I guess [Music] doesn't doesn't impact a lot there's no specs in 7692 um I don't know can you go back to where you maybe maybe this mention which you were following was just coincidence I don't know I think it would go to it would go to 3540 this one yes because it has container validation rules here oh just just oh there you go a version one validation rules so these are sort of separate from code validation rules which are different to

EIP and I would see that particular rule being added here cool all right so get that spec updated um next is there's a minor update on our jumps and successors for um in creation targets oh yeah this is this is here this is my I think yeah so this one we're adding R jump v no R jump is a j okay and I think everyone's tests had that already yeah I think this was just clarification

that Mario stumbled on yeah yep that's a good one and the next right right this is this is not contentious right so um basically if you're in the middle of doing an eof create either from a create transaction or an eof create operation if you call out to a legacy contract and they call out to the address of the contract that is in process of being created um it will come back as an empty account um and I think that's just you know there's we can't it's not a until it's been validated so we can't say it's cof and just like Legacy there's no code that exists so we'll just do the

existing code behavior for legacy that if you try and um introspect the code midc creation you get nothing and that for most implementations should be a noop but it's worth encoding and in ring in the spec and okay so so the last one is there's a lot of editorial change here but the second bullet actually there was a rule proposed on thef call that we well this allow sub containers referenced by both return

contract and E create yeah the diff is bigger because um I'm also removing the definitions here but that's like U that's bit separate um but last the last line here uh I think this show suggested by Andre but he's not here today I think yeah and I don't think we have test for the 298 line and I'll write up so I'm fairly certain Basu allows unreferenced containers and that it passes a test to me indicates we don't

have a test so we need I wasn't sure if this had made the spec yet but now that it's in there I'll definitely add it well this this PR doesn't add this line it just changed the wording this this PR adds the last line 299 and this is what I don't know we potentially need to discuss yeah if you if you actually go follow the link um which is in the pr discussion in the description yeah here this is the broader context so would we ban revert invalid only or

not really like option one is Banning revert in valids okay option two would allow those and you would still have to okay we just didn't force it you cannot yeah you can you can't have such a container but you to reference it in both your cre and return contract okay which I think has practical um benefits I'm sure some genius will figure out a way to make a DEX out of it or something so we should probably leave it

okay anyone have commentary on this or should we go ahead and add it all right maybe maybe I like question for clarification uh this adds addition validation basically validation on if the container contains only stop return return contract or it do it or it does contain only return contract what I'm not exactly sure what we we want to check so the way I implemented in Basu

when I recurs in the subcontainers I put in a flag of the sub container for how I was referenced from the parent container whether I was referenced via eof create or return contract and based on that I have validation rules for stop return and return contract if I was referenced by eof care and I see a stop or return I raise a validation error similarly if I was referenced by a return contract and I see a return contract in the container referenced by the parents um by that reference then I do a validation error so that's that's the uh impact of this is if you do a return contract or an UF create on a container that has one of these band operations for that type then

it's a validation error and I detect it while I'm in the subc container okay makes sense okay I still need to add that but yeah makes sense to add those yeah so we just need to add validation test for that yeah all right um any other questions can concerns about this okay our Spock updates are getting much

shorter and they're going along the lines of this is what we've been doing let's validate it so I think that's really good indication that we're actually closing in on zeroing in on finally being complete um with multiple implementation so this is good um testing updates I don't know who wants to take the testing update um I guess I can start um I've I think most of the PRS are already merged um there are some couple of upstanding ones but please check if there are review comments that need to be sorted out I think mostly most of the comments are regarding duplicated tests so we have

this uh Legacy containers. pii which I created like more than a year ago and I think it's like very convoluted it's not worth to have this so if you guys find a test case that it's duplicated in this file please just uh take the take the opportunity to remove it in your PR um so yeah if you see this comment just please please go ahead and just go into this file and remove the the the duplicated this cases um um but yeah I think there's not much to it but that only that there's uh PRS uh progress and PRS merged and uh do implemented um we made two two releases I think euf for euf um if you guys find

any issues with the fixtures that are being produced please just reach out uh we can uh we can fix them um otherwise just um yeah um yeah for for Bing I think Dan is the one uh let me see if he's he's here um I see him close to his button hello everyone yeah it's down here um yeah so in the R&D Discord um I've had a bit of interaction with prra and pavl about um maybe trying out EIP versioning with um with EOS and um so basically uh I mean a tldr is basically um I've been working on an

EIP to introduce um versioning for eips um that we're looking at right now and uh the proposal is still in draft status um but we could potentially like test like take eof as a pilot project for this and start versioning the eoff um eips and basically this could help us with the testing pipeline in order to uh make sure that the test version and the client versions are using the same version of the spec um so if you're interested um I've been basically prototyping um a very

minimal um version of it in the test framework uh I don't obviously we don't have it on the specs as in on the ethereum aip's side yet and we don't have it on the binary side yet uh but I'm happy to start ramping this up if his interest um so I'm reading through this is the versioning now handle by tooling and we have to put major minor or patch in one of the commits and the tooling figures it out so that would be uh the end goal yes but I think we're quite a long way away from that um I mean if you have a look at the E magicians thread um there's still quite a lot of discussion about whether we want to apply a

semantic version at all um and I think before any development work gets done on tooling this should go to all C devs and be discussed uh in a broader scope before tooling for the IPS repository gets gets implemented um but there's maybe a soft um version we could go for um as I've understood um from discussions with the EIP editors if we moved this 7577 to um review status then we could introduce a change log section in the eips that want to use versioning and as long as we um add 7577

to the requires uh Preamble of the IP that wants to use it uh so we could exactly we could start adding a section as Dano is showing here um and assuming it's ordered which I'm sure would be um we could make some tooling uh to to pass the the the first version list in the change change log and and use that as suspect version um from the client side what it needs is basically any binary that um that touches testing so anything that gives us a result like the transition tool or the eof pass tool um should H get a new flag um minus minus eof minus versions

that would give us adjacent um with a lookup of uh eips and their respective version that are implemented in that binary do we have a prototype of what that Json file should be it there is a let me just see if I've got the link in my um there is a this Discord discussion um and I think uh I did add a version at the top uh I can add it somewhere else if it's a bit lost in Discord I think you'd have to scroll up to find the Json version um that's that's the post from today um so something like this um so I mean this is this is one of the

big questions about the proposal is whether um that's an acceptable amount of work for client teams to maintain in their implementations but basically every binary that implements an EIP would have would in order for this to be useful would have to um provide uh the testing framework with this output so that we could then compare the the client implementation version with the testing version and with the version that we would pass from the change log in ethereum eips the tooling so the tooling on the on the on the ethereum EIP side I mean I would hope that essentially the change

log section could be written automatically from tooling based on the commit message um and and the and the pr title for example okay but I think we're we're long way off getting the tooling into the IPS but we're quite close to having a a sort a soft version where we could add a change log and then start using it in the test framework okay see what I can draft up this week um I I should let you know that I'm

going to be a way um out of office for for like basically the next uh two months so if I mean I'm very happy to make a push today and tomorrow and Friday no not today tomorrow Friday no we can come back to this in two months okay I mean failing that Mario said he'd be happy to pick up the work on the test framework side and um although I'll be away I'll be following uh progress on 7577 okay I would um I would still try to get things uh ready on outside before I leave um in a to a state that Mario

could take over cool that sounds good all right thanks any other test updates or anyone else have any commentary on testing status so regarding the versioning uh you can do fix or feed or feed with a explanation mark in order to bump specific versions if it's just a fix or a feature or a breaking change which requires a major update so this definitely could be

automated by commit okay yeah ex that's that's the basic idea yeah cool anyone else one last topic on the agenda there was a late ad that I put in there um so the last item that I put on as I mentioned in chat is the question of Dev Nets um from what I recall from allore devs um last week um which is by the way anyone not

listening to allore devs um eof is currently slated for Prague um that was less than a week ago but it's uh coming in Prague but it's not targeted for the next test net one devnet one um and uh it may or may not be in devet 2 depending upon client Readiness um but what we could do before we um join the formal Dev Nets is we could work together to set up our own internal devet but the question one of the questions there is how do we activate eof do we activate eof requiring devet One features do we set up the test net requiring Cancun in plus eof which might require some more

configuration on some clients or do we just be patient and wait for devet 2 or devet 3 um and just rely on most most of our um client testing to make sure that we're still compatible um so uh any thoughts Barnabas I would actually recommend to have an EF specific Fork activation and an EF specific uh like Fork EPO where all the ER clients can just Fork completely outside of the scope of Prague at this point so I would just build it on can I I don't know if that's reasonable for all the client teams but

it would be the easiest to test by far without touching any other code base okay so Cancun EIP 7692 uh from red side it's a little bit easier to extend uh prag and and just have another for PR plus CF that's easier solution because we need we don't have like features we have like level where the fork is enabled we cannot pre basically disable previous Fork could you not trigger EF at a different activation based on like know

UF time where you say on this EPO time you want to trigger UF and if we have prog Set uh not not prog yeah prog set to a date that is uh well in advance then Dr will not be triggered e would be it it could be done a little bit hecky but uh it's like if the prag inent format get activated it means even EF is get activated we can add like old feat that going to say disable that like build but yeah it can be done um how does nethermind approach

forking did we lost NE mind no we haven't ahed he must be away from his pause button um I know for Basu we also have a similar issue that that uh re has all of our Forks um are very combined together it's every all everything or nothing so and each Fork builds off of a previous Fork so um I have written in Basu code to support both but I basically had to write two different Forks a Cancun eof 7269 and a Prague eof Fork so um that's the would take on Bas who is we just

basically would need to make two separate Forks succeeding Cancun or succeeding Prague and if we want to activate Prague it's it gets kind of kind of weird but I was able to figure it out we don't have um we don't support the feature GE proposed years ago which is for plus a bunch of eips because we don't activate eips individually per se um I wish we had gu on so G could speak to their forking per process nether mind do activation per EIP I so I'm not sure if they would do that for EF as well but uh previously that's what they done and all of their geneses file has to

include uh EIP specific activation time okay guess does it based on just a single what whatever like Prague time but I don't know if they did that for E yet um I could try and pick aart uh marius's Fork but I don't know how easy would be to swap between the two um I mean it got easier this last week when 3074 got removed so that did simplify a bit so there's no op code level changes coming

in right now before eof um all of the changes all around the transaction processing and withdrawals and stuff like that um so it did get a little easier I was able to factor it out only changes to pre compiles blst oh right we add promiles that's the change that's the big change it's one line and one test that I always forget until the last moment so yeah that's makes sense in in general from how I see it they're not big overlap between e and the deite zero so in that having that in mind just extended deite one to just

having EF basically doing PR plus EF seems reasonable to me if people want to do it like more clearly like separately like U like having can UF I'm I'll be fine with that but we prefer more like prf okay and one advantage I see about Prague plus eof is it requires Prague to be implemented before we can add on eof so all the other features for Prague need to be put in place before we can activate aof which would um help address the issue that eof is stealing resources from the rest of Prague if we have to get the rest of Prague done first we

can't steal resources so that's true um so it doesn't sound like we're going to come to consensus on this call so I'd encourage all the teams to to think about it um talk about it maybe on the Discord chat group um because devet one's going to take at least a month then devet 2 is at least two months out is that a correct guess Barnabas uh we are just waiting for the consensus back to be merged uh so that might be tomorrow and then a week after that we can probably la launch de one so I would expect maybe end of the month

for de 2 possibly oh end of June before July wow moves quick uh depends how many changes there will be and how sa it is yeah and it depends if eof makes de that too or not so okay it really depends like how do you guys want to trigger it because if you can if if you could trigger eof all eof features without without touching any Prague code because prag code at this point is pretty much untested so like it would be very good if you could just test e on its own without any other headache and but it feels like uh that's not reasonable from rest and

so yeah I think we need um we need to hear from Arias before we try and move towards a consensus direction or someone else on the GU team for their implementation yeah Marius what their what his preference was for forking UF you can proceed from that we can do that all assing okay so we'll move this async um any other topics people want to discuss relating to eof I post it in the chat but um I think that we should visit the gas schedule uh

because uh according to the solidity PC article there's like a somewhat large mismatch no I think um because jump test analysis is already like uh you don't need to do it anymore I think basically the and also um excuse me uh stack checks at runtime I think a lot of the the small on codes uh dup swap ad or whatever should come down by one or two gas um so for large scale gas changes I know we're going to have a lot of large scale gas

changes in um vertical so I'm hesitant to do anything before then um since we're going to be blowing up the world in veral anyway at least for the storage operations um Paul has his hand up yeah I I have some comments about it so first of all this jum dis analysis that showed up in solidity benchmarks uh I think this is not really accurate to to like regular client so mostly the issue is that we don't have any caching for this or any maintenance in EV vm1 as the testing tool so it just like performs the the jump this analysis first time it sees the code and that's

repeated over and over in the loop if you Benchmark this somehow so that's why it kind of screwed the the result so we in the end disabled this as well for legacy so I think it's like more comparable uh I know they the like full client implementation like they they need to carefully handle this separately and I I think doesn't this this number doesn't reflect the the full client in this way um yeah but definitely you don't have to do it for yourf uh but it's hard to tell like how much um how much performance you get from this um like

for Aron I I currently try to rework code for that and this jump this analysis is like almost 0% of overall execution time because it's just cached by yeah that's like for like five five 5,000 recently used accounts and it's kind of it's kind of close to zero um so yeah so mostly we just disabled that to have more comparable results um secondly I think the gas the gas drops with ef com the solidity compiled to UF but also the the execution time drops more or

less comparable amount so I think this actually it means the gas is actually accurate before and after um that's that second comment and uh anything fig go maybe that's that's that was all I want to say yeah um I don't know I mean like part of the draw of UF is is like we don't have to do a lot of the analysis at run time like pop and KN right jump test oh yeah that's one more thing um so we

actually yeah in evm one we don't actually disable uh stock checks yet and I think it's unlikely that we disable these for for eof release it's like it's it's change that gives you like maybe five maybe 10% uh but we didn't we I think we will limit the number of refactoring we do to the evm um I think partly because EF was in evm one for like two years and yeah I I think at this point it doesn't really make sense to kind of

write it again uh probably some sometime later definitely but I think it's it's a bit risky to do it right now um so yeah I also think we can revisit like many gas schedules but I I kind of see it that this is this is probably something to do later than in the same time we ship e I think uh in a theoretical future where there's like native compilation

uh the calculus is all different so gas is not just a direct measure of time spent Computing it's also I mean we get to the multi-dimensional gas sometimes it's used to pay for storage long term um it's also going to be used um in vertical to pay for data that you add to the witness not necessarily computation time um so that's you know one argument against using strict computation time against it as a guide but again bringing up veral we're blowing up the gas schedule there if we do that that would be a better place to do it than in Prague okay yeah I just thought it

should be kind of Revisited okay any other comments all right I'll give everyone 11 minutes back thank you for calling in today we're getting some great progress done congrats on including youf side PR yep bye bye bye