EOF Implementers Call #59

Transcript

good morning today is the 2nd of October and this is eof inor call number 59 uh we don't have a large amount to discuss um part of that's because of the second item um pector formerly got split and uh eof is going to be in Osaka um first let's start with the testing update I think I want to move this to the top of the agenda because there's way too many times where we go through stuff and we got like you know 10 minutes for testing and I think at the stage we at this is probably the most important item to be disgusting um so Mario do you have any uh testing things we should be aware of um I guess ask the other teams how it's going so let's go ahead Mar with Mario so I think

the most important part is that uh the the release that contains the pr uh thef fixtures on top of PR are broken so because there's a there's a um I think there was there's there was buing vessel that that what was caught in D Tree so I think that's was what we're we're seeing on on on the on the pictures but I didn't have the time to really look into it so it uh I haven't fixed it um I haven't revealed um but apart from that um I think please the the bottom line is just refrain from using prag on top of uh e on top top of prag and just stick to using UF on top of Cancun until further notice uh we will make a release

where the uh where this is fixed fixed and probably the release is going to be uh better to hold off until devet 4 is finalized um so yeah please just keep running Cancun uh for now um what else uh I I've I've been reviewing some PRS um there's not much there I mean it's just chugging along uh PRS uh that need to be released and merch um apart from that I don't think there's anything else from my side so I've kind of been in fuzzing mpace what was the basic bug that was breaking the Prague release it it seems that there was a um uh gas accounting issue warming uh the the one

of the accounts that was that should have been warm was not oh is it 7702 related 772 related exactly um yeah I guess if you don't 7702 if you don't run 7702 tests uh from from that release you should be fine but still I I wouldn't I wouldn't I wouldn't bother just focus on Cancun and E on top of Cancun and that that should you should be fine but the point of that release was to test eof in 772 so that's kind critical one yeah um G is starting to push their stuff out so maybe we should look at doing a cross test with gu and seeing if we get the same um results so but they're not get isn't completely off

on me yet they just got the validation okay um PRS all right um anything else on testing uh just to clarify I'm not completely caught up on uh on review so there are some uh some that I have to uh review this week um um but yeah if you need a if you need a review I haven't paid attention please just uh give me a pink I will try to I will try to get to it okay testing focus is going to be on

devet for for the short term right yeah exactly so this week is is I'm fully um on on dep 4 yep yep cool so testing get that done first let's uh then do client updates any clients have any major changes rather than go one by one I'll just do a blanket call nothing from Dragon I don't see NE mind I don't see G Bas just got nothing big changed Dragon just F to say thumbs up wrong button okay yeah cool yeah all right um

compilers we don't have any compiler Representatives so oh oh speak of the devil hey Charles we're on the compilers part of the agenda anything from Hello uh no but uh we realized that uh Viper you know has this create from blueprint built in and it needs to be reworked um which is a little bit um annoying okay is there any structural changes that we might need for that um well it would be super convenient if

there were like a euf create from EXT contract okay probably not in Osaka but we could put that on the horizon well I mean by the time we rework it we won't need it anymore would have helped okay yeah because of the EXT code copy band um yeah you have to opt your uh blueprints into to working it and need explicitly be blueprints you can't blueprint off of any random contract now right right right um you know what might

be helpful is I don't know if anybody has the time but to draft the bite code for um a factory deployer um as Peter sorry Peter pointed out um you know you can delegate call into a contract that does eof create um right now blueprint prints are super convenient because you just prepend you know prefix to them and then they you kind of just like the init code just

works um so it' be cool if we had something similar that converts like a init code contract into a factory contract okay those are good points to to dwell on um uh would would TX create be of of help here um I don't think so um because usually you pull the code from onchain

somewhere yes this is my question what's the uh reason for the code being on chain because in TX create the code is hashed so uh probably the hash could be on chain I mean the user doesn't need to provide the contract code but is a the cost of the call data or what is the the reason for that being uh useful um because the user needs to provide in

in in the old way in the Legacy Way the user needs to provide the address of the blueprint as I understand right I mean not the end user I mean like the contract I mean the the the consumer of the API some yeah yeah yeah they provide the address and then deploy it then copy the code and to play it so they provide the code in TX create [Music] then yeah uh with TX create the end user would need to provide the cons the unit code right uh why unless I'm misunderstanding uh currently TX crate requires it to come

from the transaction we could revise it so you can point to um an address and use that as the blueprint uh that as well yeah I was just thinking about the vanilla T great as as we have left it yeah I mean the issue is that the user would need to the end user would need to include the NIT code in the transaction data which is um I mean you might not even know uh until runtime which address is selected which code is right so you would read it TX create reads the hash from the um from the stack it doesn't do it as an immediate so you could take in the address as a

call Art Pull It in from call data and then call TX create and if when it recognizes it's an address it'll use the code at that address if that code exists um but I think we get an issues relating to would it be a nit code or would it be runtime code would it be runtime code copy and then rewrite the data section would that be sufficient so I think that's what we would need to investigate because that does light into some of the requests that vitalic mentioned once he did want to have more cases where you could just copy contracts um is the preferred deployment mechanism I mean is kind of what create from blueprint is yeah it's a more formalized copy

yeah okay um that'll give us stuff to think about maybe talk about Devon then yeah f for some of my talks maybe yeah um so I don't know if anybody has because we're a little bandwidth constraint so if anybody and that might be useful in general uh so if anybody wants to look into that you can like DM me and uh we can talk about how it works but I think it's fairly straightforward yeah the other thing would be I think this create from contract is actually um pretty clean I like it okay um Viper is the only compiler

online so uh we'll go on to spec updates um so I guess that be has contract um so maybe actually go ahead uh yeah just about the compiler again um how sure are we about um um including it because we have a prototype but we don't really want to like clean it up until because that's like more work which is going to be wasted if it if it doesn't go in so um it got pumped out a pectra because pectra is just too huge and the current talk in ACD is that Osaka um the

Osaka devet they're going to add perer da and they're going to add eof and that's before they consider any other additions so that's kind of going into this some of my next discussions um about what the what current shift that we need to do with with uh eof so I'll probably just um start with that and let's set the table um R this back up migration so for people who haven't been calling into allore devs or reading the news um like I just mentioned um eoff is out of Petra and that is so they can attempt to ship Petra possibly by the

end of the year at the latest q1 um with all the other features that were in pector was looking to ship even later than that um so they decided that what they had in devet 3 alone is enough to justify a fork so they're building devet 4 they're doing changes to what's in devet 3 they're contemplating super emergency stuff um you know stuff that is critical and must go in with the next six 3 to six months or it's going to be a problem they're discussing things like maybe a Blog limit blob limit increase and other smaller changes but that's the only thing that's on the table for Petra is stuff where six months is too late um for the help of the network um so in that regard the door for Petra is closed

and as part of that discussion um the remaining stuff from Petra which is right now just p and eof and about four stray um eips that haven't been formally scheduled yet but there strong preference to schedule them those are targeting Osaka so the uh the decision given on ACD and the process of going forward for um is the devet 4 will come out here in about a week or two um and then they're going to push to get a Osaka DEET zero started um that will include just PS and just eof so where that puts us with our implementations for the clients um we need to Target Osaka for eof activation that also means tests need to

Target Osaka including moving tests considering that we've never really hardcoded in um Prague in a too many these tests I think we've always understood that Prague was too big and that if there was going to be any split of Prague that eof was going to be in the second half so this really I don't think is surprising it's something we were prepared for it's something we were braced for um but now it's it's it's going to be in Osaka or it's never going to ship is kind of a bube I get um and there's a lot of strong pressure to have it chip they're targeting I think Q3 is I think the current Target um so given

that um that we have 6 more months to refine the spec that opens the door for some changes that we were pushing off saying that we could not um do it in time and I think the the top two items on that list the first one I would actually probably put them in reverse order in my notes is has contract and how we're going to handle um 721 and 1155 uh contract size um I think we have time to um figure that out and really get it locked in for what's really going to be the long-term solution whether that's a new OP code whether that's

exposing EXT size EXT hash whether that's um not putting them in and sticking to it and saying this is the plan going forward um we have time to work that out and figure out what the correct solution is I think that also gives us time to prototype what it would look like to show how these things would work um with some examples um so that's I think probably the big gain from from this the second one um I'm bringing this from some of the comments I read in gets U merging of the EF code so they started merging validation they just pushed that this morning um they're going to be moving in bit by bit and this is into gu main not a not a fork but into actual gu main so this is I view this as as good news um

that um it's going into main so we're gonna have it in Main and three three clients um mostly functional in the fourth client well NE mind hasn't merged it yet um there's still a few more bugs but this it's you know we're we're in the last lap absolutely in the last lap of getting this shift um uh some of the comments that they had in there there was concerns about um the op codes the return from the EXT op codes um ones and twos um part of it was was a test coding issue I could search the test code as well to see where the ones and two returns were different different so I updated the tests and I normalized all EXT return codes and eof create

return codes to use the same standard set so we can do a search for these but they're concerned their code is it looks like they have to patch out different errors and look for specific text and errors one of one of the arguments is is guests to change their code to make it easier um but it also opens up the design question of do we have the correct return codes for these and should we step in and see what's going on with that so those are I think the two doors that are open right now and there might be room for more stuff if it's brought up but I'm personally I'm not looking for new items and so that would be people needing to bring new items up and say that um those would need to be revised um comments there were some minor items

that we are sort of clean up more of a clean up and convenience changes that we have been talking about like the E of create order of arguments um and this ma stack height that could be revised and made more more convenient to to use create yeah but these are more like cleanup uh stuff um what else um oh yeah removing the hashing of the init container in E of create and one name change for up code so

that's only the hashing of the init container is one that might be more involved what up code are we looking rename uh return contract to return code just not to say contract because for the evm is kind of know Bish okay so if we have clean up items like this you know this week and next week are the right time to bring these up considering doing those after def four but I guess this means Osaka definite

zero I'm thinking we target one I think that Asaka de at zero we ship what we had that was ready to go yeah I mean after like after zero so yeah I think Osaka one is when we start shipping some of these wish list items yeah yeah yeah and part of wanting to ship it as is in zero is I kind of want to show that we were ready to go forward if we needed to with what we have tot yeah totally agree um does this mean sorry I've been um out for a few weeks I was um taking some time off um but does this mean that the spec is open for um adding some of these cleanup or kind of nice to Hales

that were tabled before uh like um the encoding of immediates for example um for small items I think the varargs might be a bit too much of a change the variable length integers um but like order smaller things like you know stack order names um and things that are that um Downstream users have requested so um this the uh variable length integers would put a limit of 64k on contracts but right now we're still at 24 so that's something I think we can address in Amsterdam or bog but that would be the sort of things

we might be able to discuss anything that goes in we realistically need to be able to do in like a month or two um and then be ready starting in Q2 to be in ship on the ship on sh notice mode okay and um I know we got lots of push back in all Court devs over uh uh ERC 721 calls EXT call is a smaller one stack order is a smaller one hashing and the CH been something we've been worried about for a while and renaming is I mean we could probably do that for devet Zer

if we need to so um but if there's something of that level um we can look into it and I think I think VAR my personal opinion Varin are best served with a separate set of codes um because there will be times you don't need them and there'll be times they're essential but yeah um I think that I mean my my opinion is that they're like generally useful I think it could also like really simplify stack op codes because um with I mean yeah if you have a variable length immediate it really opens up some possibilities but yeah yeah variable length push would be

cool that would solve a lot of issues there we up a lot of op code space um but I think people would freak out if we got rid of most of the push instructions yeah variable length push variable length swap um would really yeah it would solve a lot of problems okay so what are people's thoughts um is this stuff we can resolve today or

should we get plans for next week to address these six items on the list in for two weeks I think we can address them now okay if have if we need additional person to say yes let make it three okay so that that's basically the end of of my agenda of what want to discuss today um do we want to go back over some

of this do we want other issues to be discussed I've got a question but it's um maybe could be taken offline let me know um basically I want to understand the extent of uh the gas introspection limit I've been working on EIP to convert gas to eth and I'm wondering uh whether that would be in bounds with UF so been talking to some of the L2 people on this one of the reasons I want to be as far away from gas as possible is some l2s are seriously going to be approaching multivariable gas in the future not just changing the gas

schedule um but having different gas buckets and different values for things like storage things like really expensive math operations like f check would go from a different bucket um because that's really expensive in ZK um stuff that's expensive to do a fraud proof for might have a different bucket so there's there's a push to go into multivariable so um as far as you know giving access to some of those the gas inpection anything that presumes a single variable gas I think is is going to make those multivariable gas transitions more difficult um so that's um whatever we have with that would would need to take that into account somehow because I

could also see I could see some if this is valuable on mainnet I could see valuable on L2 to say let's convert my storage to eth and you know do Arbitrage with that um whether or not they want it's a separate discussion um but if it's possible on on L1 then it should be possible on L2 I guess is the short the short answer and L2 is can decide how they would want to ban it if they wanted to or address it or not worry about it so multivariable gas is like multiple gas prices or multiple gas limits because the gas variable is still just like how much gas is available right still like a single number no it would probably be both so there would be a separate and um yeah so there' be like

gas for execution gas for storage gas for cryptography and there be separate limits um and there would be separate um transaction rates between one storage gas to to Ether and one execution gas to Ether or whatever their native token is op token or arbitr token um as far as what they would burn so those are yes it's like full VAR multivariable your contract could fail by maxing it on any of the three um your your your gas your cost for transaction could go through the roof because of any of the three if someone's running a storage spam attack storage could become too expensive for everyone so that's you know that's some of the issues that are open for multivariable gas um but based on some

of the uh um some experim being conducted on alternative layer one chains I think we're getting the answers to some of our questions for some of those concerns so there's yeah the that be itd be full full fully independent and fully separately controlled of each of the gases and an OP code might consume multiple for multiple buckets at multiple rates yeah I think I have some more questions about that but I'll take it off fine with you okay okay so um

my quick take is we need to get a plan to get uh the Osaka um activations done but that can wait until we're done with devet Forge so probably next week um if Mario has it I'll get a PR to move everything to Osaka um once devet 4 is um a little less obscuring the battlefield um and that means we would need clients to adopt to this um and and execute and open up Osaka uh and I think that's yeah that's probably the biggest changes there's no other

comments I guess we can get a half hour back so everyone seems pretty uh burnt out from the from the pushes get some good valuable time off it's has code not has contract for has code yeah whoever was reading as cud e

this one's easy let's do this one first that way we're sure to accomplish something nice all right thanks everyone see everyone in two weeks