EOF Implementers Call #51

Transcript

good morning uh today we are doing eof implemented call number 51 uh the agenda is issue number 1074 and so far we only have the standard um the standard tests and the the standard agenda items um so probably spent a bit more time on test there are some questions dribbling in on chat that we'll be sure to address uh but first let's start with client updates starting alphabetically by people calling in um Alex do you have any evm one team do you have anything on evm one for updates any evm when people can talk I

think not much the in it called mod validation is still in progress tests are atent U on on on the are being Workman right now by Andre and uh we've got also the maxim code size validation in review and I mean it's a basically a waiting resolving the uh execution spec test dependency in CI but it's also implemented I don't know if there there's anything else being worked on right now okay um Dragon RM uh yeah uh the last week I was like

fixing bux for rvn didn't pass test test fixure to so I will fixed that and I found all of them and I need just to clean up the PRS and merge them in and after that I hope that f is going to work properly with the custom UF solidity compiler so yeah I'm basically working on that okay um yeah he posted a question on test that's something we need to discuss in tests whether we continue to build off Cancun or move to Prague yeah um so we'll discuss that in that section um for Basu um the one to change from last last week

where we um do the container sizes uh currently working on that I made the mistake of doing a large refactor part of it and the larg refactor went poorly so I'm um stepping back doing a simple fix and can do the reactor independent to get that fixed in it's not terribly difficult fix I know where to put the stuff in um so that's the only um outstanding issue for Basu right now um Marius GTH uh yes um not much happened for me I'm passing all of the uh code validation tests except for one I think um but I couldn't be

bothered so uh and um I'm not passing the state test bunch of things that I haven't implemented yet bunch of cod that I haven't implemented yet uh so I will be working on this um otherwise I uh worked on the like these dos uh things a bit and I will be upstreaming them to ethereum tests so we have them um whenever we need it and um yeah that's it I just needed some time to work on something different uh for a bit and but I will be coming back to to to

it this week I of curiosity what was the one test that you don't pass right now I don't remember I think it is oh it has something to do with the max St Heights po no um I think R jump Max deck height or something I don't I don't remember I I can look it up um and I can send this in the CH okay yeah our jumps and stacks are sure there's just an off by one or a less than an equal and it should be a less than or it's always something silly

like that has been my experience um when I've been trying to struggle with just one do we have anyone from nethermind on the call do we have anyone from ethereum JS are there any other Mainline evm clients I have not asked about okay um next question would be for compiler updates uh do we have an from solidity on the call no Charles do you have anything

this week for Viper no updates from Viper okay um the solidity PC any significant changes in the last week or is it still just doing fine so maybe I have from Epsilon many people were either off last week or off this week um so that's why the the lack of response on some of these I don't know if rodic made any more progress on the solidity Branch uh but we're looking at doing more benchmarks um like gas gas and size benchmarks with popular contracts and one of them we haven't

completed it but one of them is the p256 verifier um which uses significant gas like 330k so hopefully that um yeah the number will be less withf cool um any other compiler updates cool uh spec updates um we don't have any spec Updates this week I'm hopeful we may have had our last major spec update although um Marius wants to talk about updating eof in the future is it okay if we do testing and then loop back to that question

Marius sure okay um so let's go to testing um anything from the testing team they want to discuss or qu ask questions about before we go to the eof Prague eoff question um not not that that much major things um we've been reviewing um the pr stuff and just trying to merge um at the tests um I think one question was related to one of the code size uh tests that we have and there's an actually an open PR for that um that implements code size so uh my question is I think

this um we should have like two types of tests uh for the code size and validation and I think when we try to do do some oversized uh uh containers I think that should belong into the EF test fixture type and for the for the current um for the creation of e of containers and the validation that the containers are not oversized we should use the state test um uh stat test uh format uh I place a comment in the pr um but I think I think we we should um maybe async in the pr we should we should just uh get this discussion um

just just to know that we are in sync with the with the way that we are testing oversiz containers yeah so I responded to sorry no no please go ahead I responded to this question I this PR in particular just had a very specific tests for in addition to the spec which is the max init code size e validation time check and I think we still um need to fill the gaps in coverage and in general creation uh state test it's like kind of a separate story but agreed that we should um test on both fronts all right um cool thanks um yeah and there's uh another PR from the from the testing

side is uh this one it's related to EF because um we now have the ability to um automatically calculate the Max St stack height in the code that we generate for tests which means that we can out in theory if the go for any previous tests uh I mean pre Cancun and all that stuff if we have uh go that we use to test um any other functionality like subst struct like uh pre- compiles Etc we can now update this automatically uh to to generate a

container in theory if it only if it doesn't call or use any of the duplicated upcodes that's something else that we have to figure out but for the time being with this spr the max stack height would not be a a blocker to automatically um convert something into the EF container um so yeah um this this BR is mainly mainly um test changes and that are unrelated to EF but I think it will be helpful for for EF yep yeah this is good stuff this is good stuff this this will make testing eof V1

and uh Legacy op codes make sure they operate the same a lot easier cool it's I have to say it's not perfect though because there are some things that we simply cannot uh predict for example when you use call F into a another another code section that contains more outputs or or modifies the amount of outputs that it has that causes some issues with this but as you can see most of the max max height uh lines are removed from from the UF tests right but Legacy is not going to be um call doing Call F so we should be fine there for its what I see its greatest

value so awesome this looks great makes the makes writing tests a lot easier yeah and and as you can see there there there were some some St instances where I think the value was incorrect and this thing caught the difference um so I think it's it's beneficial that we don't have to calculate this manually uh and we just let this uh this St do its job and you we only hard code this value if absolutely necessary but yeah that fixs me I mean if if the test is to get it wrong of course you have to get it wrong in the code but yeah that makes it easier and overall it just it's just a

great addition to the to the testing framework um yeah it it has other benefits also but yeah EF is going to be benefit uh the main beneficiary for for this I think cool and it for me that's it okay yeah um so Dragon brought up an issue that's kind of related to another issue um there is a discussion of starting a separate test a separate devet before we go into the full Prague um devet series March that is just e to kind of try and shake out things before we go into full devet mode um and one of the questions is is whether we build off of Cancun and whether we build off of Prague and if

we're going to build off of Prague um that leaks into uh reference tests on the the East tests because um do we build off of Cancun or do we build off of Prague um one issue I've seen is when we do Prague tests um all the state tests and all the other tests are going to start introducing um changes to uh things like the um uh the the um block hash stored um which will produce different state root hashes um they're not easily discernable unless you know to expect them U from a state from a state test because you just get a

different hash and you are missing um the ox25 etc etc class that is storing the the loock hash um so that's one one one issue that that I've seen between the fixtures that evm 1 creates and Bas cre Gres and I'm not sure who's necessarily correct in that case Barnabas we were just talking about test Nets so you joined right at the right time how can I help um we were having the discussion about whether we build off of Prague or Cancun and I was just teeing up the issues around it and one of the things that leaks in if we're going to build um

Prague e instead of Cancun eof that we should um have reference tests um require things to be integrated with Prague and I was doing a temperature check to see what other client teams felt about bringing in all the Prague stuff into their eof work last week if I remember correctly we discussed that we would try to put it on right after Prague so it would be Prague time then Prague EF time trigger it U just to say that's like that's something that I said but it depends like on other teams what's the best for them for red side it's like it would be best if UF is included after prag basically you have

prag EF hard workk but I can make it work even if is on top of the conc depend just like what's easier for people I think it's just when we want to test because if we want to test ASAP then probably makes sense to have it uh top of Cancun and just stop all emerging and just get up and running but if you can wait another week or two then we can just probably have it on top of H PR yeah go ahead from the reference test side I think the only change I mean on the actual test code the only change

that we need to do is just one line basically but the problem the blocker is the transition tool so we need a transition tool that supports um bra and also e so that's that's our blocker for testing do we need to have the activation trigger with Prague eof time can't we not do just eof time and just have it activated independently of Prague um at least the way Bas is set up um all Forks have a parent and they inherit all things that are activated in

the parent so I have a PR set on the side um that is a Cancun e that activates Cancun and adds the eof stuff on top of it um so that was you know one option to go with the Cancun e um is we can't it's not easy for Basu just to turn on a random feature I don't know what the other client team setup is for theirs uh it's similar setup in rvm and yeah red has little bit different setup but for rvn it's a lot easier and it it was faster to have just one gate let's say we can have we can basically have two hard fors one for Cancun UF and one for

prag UF where the Cancun UF will be on top of the Cancun and SEC one on top of the Prague I would like to have just one of those because it's not uh it seems like I could basically add both of those but we need yeah we need just to decide what's easier I yeah little bit I have a little bit more preference on prag UF but because prag AIP seems mostly like it it require just like 7702 and that was it and that's like different transaction so if we're not setting different transaction we're not like uh having iion between UF and

7702 and pre compiles from De Z and TR from De Zer seems like in okay State yeah I looked at the 7702 for PR that the other base rest of the Bas team's working on for 772 and it touched like one line in eof and that was just the gas calculator to add a constant so yeah 772 is pretty orthagonal to eof um and because I ped Marius last week his opinion on it and um correct me if I'm wrong but he could go either way and doesn't have strong preference so um would it be reasonable to ask each client team to have then two activation possibilities canun and

prgf and then we could test right away with KF and then when whenever prgf uh rease is done then we can just deprecate canun I'm okay with that it's I I don't know how much time how much extra time that take but like if it's very uh easy to do and then we could have like a devet up and running by the end of the week then it might be worth it assuming that the eof implementation is actually done by all the different yeah things let's go to the test metric the uh Matrix and I'm not sure is this up to this is an up to date this is the update

that's PR I I've just opened a PR with an update yeah the background colors have updates so I don't think I mean we could get um maybe revm and Basu by the end of the week possibly um but if it's not the end of this week the next Target would be next week or the week after is that what I'm hearing from Barnabas I mean I I don't know how long the Reb is plan to be for gas for example or for nether mind so if if it's just one or two weeks to repase then it might not worth it to add the Cancun UF to it and just go with prag from the Geto so do we have any uh word from Mar

maybe how is G this doing it kind of depends on like we it can go pretty fast uh it can also take a long time I started reviewing the first um prag he uh prag um PR and uh the problem with the way we did prog is that we have a bunch of PRS building on top of each other so we have 611 z uh seven seven

oh 7,000 7,000 to yeah um and then the depth net those are kind of three PRS spit on top of each other so we we need to go through them one by one and match them one by one and um there there are some issues with six 110 because we need to unmarshal the deposits and and that was actually something that I wanted to ask other kind deaths about how they are doing the UNM Maring of the deposits um and what happens if they if they fail but um probably different

context than than then we discussing right now so I will keep that to another call uh either way I guess we can probably do two or three weeks that will be my guess and how long would it be if you would need to add another activation time like canun um the problem is that we don't have any any PR EF um activation in yet so um it would it would take me maybe a day or two but

that code is just going to be thrown away so so it's not yeah so it's not worth it you think I I wouldn't I would say it's not that yeah not really worth it okay so should we work forward based on a Prague e devnet next week probably then or the week after sounds like week after is probably more yeah sounds like the week after is a bit more reasonable it it depends on when the rease is done okay yeah um yeah Bas is ready to go um when we need it um so I think that we should be our Target

for when we launch a devet um be great to launch the devnet with everyone but you know other clients joining late is pretty standard for Dev Nets so I mean we can do cusis test right away like today even I I like yeah I I could add like one flag okay maybe not today but tomorrow it's like 6 PM already here but yeah don't do it today yeah I I could I could add the Cancun eof time uh as the activation EPO for uh our Genesis generator tool and then I can add that to the etherum package and then we can do local cryptosis stats by Morrow um basically we need to get their

um get our Cancun fpr merge but I could do that yeah um we we still have no way of actually testing it right of triggering EF stuff on we would need to hand create oh cryosis can you send random transactions inside the cryosis does it expose the ports to clients y but so what we would need to do is uh update the x f maybe to do EF transactions but there's no way of doing EF transactions right we would need we

would need an EF contract in the Genesis no 7698 should provide a way to introduce eof transactions you take a create transaction you put your EF code in there and you put your Ox data after your eof container not your Ox data your input data so that's 7698 is how you bring eof into an existing system just through a regular all create transaction and you have the solidity PC to help you with this because this this is what solidity PC uses to deploy I see okay we can deploy un swap what else we

tested I don't remember NS I think you swaps it might be entertaining to uh try the open Zeppelin contracts I do hope that we'll integrate it inside found so it's like we'll have gas and everything around it do you plan to have fundry integrated in soon uh yeah uh the the problem was uh rvm had some bugs so I just like found the last one I need to clean up those PRS merge those and like propagate the changes to Foundry we

started testing it have some integration with it and yeah it is not that yeah it's it is easy to do uh last week I've been working on last couple of weeks I've been working on some uh optimism stuff to to have optimism roll up on top of the etherum package so we could potentially check if we could roll out a EF style uh contract deployment with uh the optimism stack yeah have be op WTH op base is not ready to go yet oh yeah the op WTH uh that's what I yeah yeah that's amazing

to be honest yeah I someone from op ping me on Twitter I should probably let them know that that's a possibility that might happen this next week yeah I mean that assumes that the solity code is changed to be compatible with eof code I I'm not sure if anyone would be quick enough to do that because I have no idea what any of that means so go ahead yep it's in like proof concept but it's like working that's how the the stats for the unisab contract and ens are basically made right uh so to activate the do we

need to have some contract deployed or nothing special nothing special okay so what Happ so what happens right now is when a contract a create transaction sees EF of any way shape or form at the beginning is the first bite rejects the transaction so 7698 if it says EF 00 and it's a valid container um with possibly some uh init code overhang then it'll deploy an eof contract so that's how you bring eof contracts into the system is through the create transaction or through the Genesis file so we don't need anything in the

Genesis file for us to do validation okay sounds good so at least we can turn it on and see if smoke comes out so that's that's good news so yeah keep us posted don't don't don't bash your head in if it's not working too well just let us know it fails yeah uh we have a new interop chat on uh ether Andy I'm not sure if you guys are aware of um is it in the testing group or is it in a different group yeah it should should be in the testing group so we have a e specifically EF testing within the testing group yeah so let's um let's keep those

updates in the probably eof testing group would probably be the right place Cool Beans all right let me know if you have a bz Branch uh ready to go with the activation time yeah canun e time activation trigger okay I'll put that on my to-do list um I have a yeah I have checked in I just I'll I'll publish a PR um what would be the trigger for nethermind by the way would it be all the different eips or would it be the one big VIP do you have anybody from nether mind

is I here yeah uh we don't have a lot of updates we are working on EIP 7698 and you are trying to see to implement it and test it uh my question was what would trigger uh youf in the chain pack would it be all the different EI P time stamp transition time stamp or would it be something else I guess yeah we'll go with the same time stamp for all eips for all for all efps so we I so I would need to Define

all the different uh eips in the Genesis uh chain PC Oh you mean like a separate EIP for each change or one one big one for the full E I don't get the question it doesn't exist right now for us we have just one field we have to set true for E to be full like activated completely yeah but how do you do that yeah what is the field name that's that's my question is it activating 7692 or is it a different field name

oh uh its name is activate uh let me check I don't remember exactly the name but I think it's release [Music] back okay uh is eof enabled eof enabled awesome eof enabled time

stamp or uh we are just calling it is e enabled and if we're enabling at Genesis that should be fine uh I don't want to enable at Genesis I want not fine then yeah I I I do want to to test the fork transition for sure so uh enabling it in Genesis makes little little testing on so like I I want to be able to send transactions before before and maybe in you know EPO two or three to test if you can transition I don't think we added that one

yet okay can you please add that then uh a way for me to activate at a specific uh time yeah yeah uh what do you suggest I call it isn't there a mega EIP for EF yeah 7692 769 okay then then I will call it uh 7 EIP 7692 transition and whatever value you provide it will be used yeah okay yeah let's let's do that then cool

7692 copy paste tomorrow's allore dev's execution correct yeah I think so okay um any other testing updates before we go to other items okay so um one thing I'm going to propose not this week but next week we start doing is we switch to every other week uh live calls and we are going to

uh do a lot more async um stuff like getting the dev Nets up and running and and dealing with bugs uh the reason I remember us going to the weekly causes we had a lot of spec issues that we needed a lot of quick iteration on um we have no spec issues this week so I think this is the right time to consider going back to the every other week Cadence which I think is a much more sustainable Cadence I know that's what vertical trees does and that's what a lot of the other breakout rooms do is every other week um so we would still meet next week but after next week um we would meet every other week on the weeks where acde is not on what what are people's opinions on that seems reasonable yep makes

sense okay so if there's uh no objection we'll start going to every other week starting um next week we'll meet and then in two weeks we'll have it off so this would be the last off-week call is the way we could look at it cool um any other questions or comments or items that need to be discussed before we end the meeting yes I wanted to discuss quickly um discuss upgradeability upgradeability yes I forgot that that's why I always ask for okay um so one thing that I kind of noticed when when when thinking about

our stack validation is if we add something to it we will completely break it and um so if we ever decide to to add a new up code to e um any up code uh we will break the second code validation right and so we would need to have a separate version for every hard Fork my question is have people already thought about this and if so how do they handle it when this when when when designing their code because right

now my code for the stack validation it's I don't know 150 lines uh for the co for the codee validation 150 lines for the stack validation 200 lines and those are two different functions but if I would have to version them I would need to basically make a copy of of it everything else would be pretty horrible so my question would be have other people thought about how they would like to do this and if so if there are any better ideas than just

copying 350 kinds of code so I've thought about it a bit in Basu in our code we have the notion of a Max eoff version um and that goes along with my mental model of how I expect eof versions to evolve if you'd imagine eof1 being a set of all possible contracts that are valid any forward compatible change would take code that was in the invalid set and move it into the valid set and anything that's in the valid set would not become invalid so if there's something that is a valid D1 contract if we make a change it makes it invalid we now have eof V major 2 but if we have a set of valid

contracts and we turn on off codes we don't have eof v11 and I might encode it internally as one two three um Java's in their class file format just monotonically increase it I think they're version 55 um for their compatibility even though they're only on Java 21 because they would increment it um Whenever there is some sort of a a change um and like 55 could only go back to 51 for compatibility there's kind of a matrix on there but my thought is that we would take one set of validation rules for eof1 and for certain rules we would also say like let let's say we're adding back um we're adding in um what's an OP code EXT data copy so we

put in another thing it's like well if eof version is greater than two and this would be EF minor version in that case or greater than one or whatever value it is it's you know version two is what we're bringing it in um when I would check that I would check that it's there and if the maximum EF version is is two so when we do the validation function we would pass in a parameter saying what our maximum eof version is so in basically we would still have one code block would validate all the codee and validate all the stack but if we're validating a rule that was relaxed for v2 we would need to have that flag to set it and by relax you know typically it would say include these op codes and then necessarily do the op code validation I'm not anticipating any

changes to stack validation apart from what the op codes bring in with them um but you know in theory we might just say e version 3 YOLO on stack all Stacks are valid so we could just say if e version is three passes on that's sorry about that I lost my microphone but that's that's my perception on it is that the future versions relaxations would be triggered by flags that we passed it as a function and I've already got that written into the evm spec in in Basu so that we got these things built it that's that's my mental model so we don't have to copy code validation and copy stack

validation for every major version going forward otherwise that's going to be a rich source of bugs yeah makes but that only it's only really clean I for or like very easy rules right like if we if we I don't know if we relax the backward jump rule or whatever

then it would be very hard to to do that as a flag right I guess that does limit some of our forward things we could add which I don't see large changes on the the the rules stack validation going forward yeah okay but yeah that's yeah yeah it makes sense thanks um um now I know how how I'm going to maybe do it in the future I will I don't think I I will implement it now because it's not needed but yeah makes it easier to

implement it in the future for sure yeah that was it all right any other topics of discussion or comments or question all right if not um see everyone back in seven days and see most of us tomorrow on ACD thanks for calling bye thank you bye thank you bye bye