EOF Implementers Call #44

Transcript

all right um going to start eof implementers call number 44 um probably going to be short one this week um a lot of the Epsilon team is out uh it's a Mayday in Europe um it's kind of an important holiday there and a non-holiday in North America um so first I'll start with client updates um in the process of writing tests Bas who found a few implementation bugs and fix those to our Mega E Branch um I also took a test run of ev1 and gu through it I don't see any gu people on the call um I think there's one one test case that I wrote that evm one has issues with and it might be

because they're doing the verification at a different part of it so the test case might not be terribly um appropriate has to do with uh innate code overflows um gu is it got some pretty good progress um they are not done implementing EXT calls and they're not done implementing creates and that's most of the tests have written so um but the other ones that I can see for the most part yeah there's there's like an off by one error and a gas calculation error on one of them but those are those are you know typical and easy to fix um not surprising at this point so I think they're doing they're pretty good with their progress um Amon you got some information for NE mind uh uh you mean like the branch or what uh the how's how's eof going in

nethermind doing uh it's a little bit off track like a little bit late because we were focusing on on IPS for the devet and we're just getting back to it again this week so okay um does nethermind have a um do you support uh execution test specs per chance execution the P tests do you have a runner for the P tests I think yeah okay so I'll probably P you when you get a little further along to share your branch okay and we have a

t8n branch that is getting implemented as well so hopefully soon we get we'll be up to date with everything okay cool um Hugo anything new from evm one um no nothing from my side I've Miss I just been working on some small changes uh related to the the the tests that are exported from E1 to the to the uh ethereum test suit okay

cool next on the agenda compiler updates um Viper not not here Viper's here solidity is not here Charles get anything on from Viper for updates uh no uh I have been hearing murmuring of when are the compilers going to implement this and I was wondering how important is it is it just for like um what do you call this like shims like people want to be able to like test it end to end from source code or uh is it more like it makes it easier to write tests um so the big ask is coming from the verical team they want um real world

examples to see um how much bigger or smaller does eof make it what are the code traces look like um because they're they're concerned um that it might Implement veral um my thought is that it's going to be about the same impact that legacy's going to have um but they they want hardcoded data so that's where a lot of the push is coming from but also um getting getting compiler Support also I think is another important shelling point in moving this forward um because we can you know produce actual code and people can start seeing um what the impacts are and it makes it feel like the spec is that much more solidified if other tools are generating

to it it makes it more feel like it won't you know move around so that's those are those are two of the two the uh um two two the things contributing to the request for compilers for implementations yeah [Music] um I think that the code size is going to be roughly similar although um solidity for the Shanghai Fork they implement did with EIP 663 and we did not

um I think uh it's not the way eof is speced now it's not strictly better uh in terms of um okay it would be strictly better if there were Global code sections instead of sub routine sections um um and so could the compiler just Target one code section instead of multiple code sections no I mean that's like one reason I've been asking for all these changes to the analysis and I've spoken with Pavo briefly about the feasibility of it and I mean this was months ago and

he said it's fine like it could be done either way but then I never saw any movement on it um and and the reason you can't is is because of the stack validation rules um what what was your ask from Powell what what didn't move forward uh he said he'd look into it and then I think it just kind of fizzled out okay um probably probably there's it go ahead yeah I don't know maybe there's other priorities or I mean I think that a global code section is is important um for for eof that's one of the reasons I think this I mentioned on ACD that I

think the spec is like not perfect but so Global code section meaning there's only one code section in you sub routin within it somehow yeah yeah EIP 2315 style sub routines and there's like a very long ethereum magicians thread on this from like 2021 which I've read half of right I soon recall that um solidity didn't like it they thought there were some code size aggressions and solidity saying they wouldn't implement it was was critical to having it pulled from burlin I think that with I I think that it's better than euf

code sections okay in terms of code size I think like the spec I mean the specific the the specific design might have some weaknesses but I think that style where the code section is global is like strictly better in terms of code size okay because you don't need to make a gas code size tradeoff right right um there's no well is there a is there a jump test equivalent for sub routine start um I don't remember how the e works but it's it's going to be less than

three bytes which is the typical well yeah it's at least two bytes for new code section because that's the extra size info in the header yeah and then another four so it's six it's a six bite overhead on subes right there yeah I'm not concerned about the sub routine header overhead although that's like also kind of fixed by like variable length um items in in the in the header spec um but I'm more concerned about code sharing so there's like a lot less you

can do when you're forced to like share code by putting it in sub routines instead of just having shared code sections that you can jump in and out of although the the changes that were made to jump jump fi uh improve that a lot jump F not jump fi because we don't have jump fi yet right okay um all right yeah the ipsilon team isn't here to discuss some of those issues I mean if we're if we're going to stick with our product delivery date we unfortunately don't have time to do that

but if if that opens if that door opens then we might be able to have another discussion um that's yeah so we'll see what the status is in the next few weeks yeah I mean another thing is like I've gotten this consistently over like the last two years where like uh you know I'm like can this be changed and then the first thing that comes up is like we're close too close to delivery date and then like but like delivery is always like or like freezing is always actually a long way off well we were trying to get this in for Cancun before we rooted and then Cancun was supposed to ship six months before it did I agree with the frustration that

we're always in freeze mode and we can't ship and that's really hurting the process right and that's actually one reason why on the last ACD call I was like uh it would be really cool if we could like have an L2 or some kind of kind of test net for this where we can actually test and evolve the spec instead of always having it be freeze mode and like the you know push back from ACD over like whether the spec is too big or too small or too Frozen or not frozen enough you know um yeah if there were like some semi- production environment

where we could actually evolve the spec I think it would be really good okay yeah the problem is getting a shelling point for what the final spec is and yeah yeah I mean now that we now that there's a couple imp implementations on on clients we could set up l2s um I don't know how op basus going but um once we get a GU implementation uh mainlined or even in even in a standard Fork it'll be a lot easier to do an OP gu uhhuh um it doesn't excuse me uh yeah I think test net is the first step and then like L2

MH yeah actually I'm not sure if you even need a test net like eof is just evm right like you don't actually need the protocol in order to like use it um I think the thing about an L2 is it it like proves to people that like it's actually viable in an economically um what is this called um production environment right it actually is in shipping code which changes people's minds a lot um and also so we do have we do I do think we need some bit of testing that interrupt for the um create mode transaction not

like um the sort of interrupt testing required for the like the engine API and peer-to-peer stuff where what happens in production you know there's lots of failure modes um there is no failure mode it works or it doesn't so that that does simplify it but I think you know for people to interact with it and you know spawn ideas and get people to see it working in action I think will you know help a lot uhuh I also think that the design of EF should be different depending on if it's before or after veral um because if it's after veral then the data section like almost actually don't make sense well I mean we still needed immutable

data section you know solidity is going to be rewriting their code um to put the data in I and the actually do for immutability is not just about cost savings although that is a big issue it also is about you know the the auditor comfort of it being in the code and unchangeable uh in the front end code or in the bite code in the bite um I don't know I mean just because you see immutable in solidity or Viper code doesn't mean that it's stored in code in bite code but if we take away data then there's no way to stored in bite code

and in the contract then you just stored in storage which can be mutated and if you put you use delegate call in your code um that opens up the door to having your storage mutated with a bad reference of a delegate call and then you have to do an audit make sure all your de delegate calls and all your delegates are set up properly to not mess with your storage it's just it solves a whole lot more problems is having the code immutable data in the code in a truly immutable section and not just hope that any of your delegate calls don't happen to change it um another simpler yeah I mean I don't think the alternative design has been considered where we add an immutable uh memory region uh which would be like maybe

annoying for some people because like we already have you know call data storage trans storage whatever but we already have code data and if we were to add an immutable data section we'd have to figure out some way to store it and some way to Signal it that it's read only in the tree yeah I just don't think that design has been um considered really yeah it hasn't been deeply considered it has been implemented with real a real alternative the the problem there is that starts getting into more deeper fundamental changes of the evm we're focusing on one at a time right now that's just the container format if we start messing with memory um then the arguments that this is no

longer evm actually become quite valid I don't know I mean like in some sense the data section is the new region right right and it it parallels the existing region of code and the existing evm so it's a lot more like evm than adding a fourth class of memory uh kind of I mean it is the fourth class of memory but it parallels a lot of what's done yeah right because there's some design

tradeoffs I think vitalic is right that create copy of code is simpler than eof create probably is and that that's one of the reasons that's one of the things TTX create out opens up space for us to explore that it's not essential for the first rev and that's why when I took it out I made no promises that it was coming back in the future I I myself am not promising that TX is coming back as is I even recently just pulled the code out of Basu yeah so I'm saying is that uh before depending on whether it lands before or after veral like the design could and should be considered differently like there we should spend at least like one

or two meetings like hashing it okay um but yeah or maybe even maybe even not that long maybe half a meeting or 15 minutes or yeah I think that it should be like in the considerations section of the of EIP okay um write a not for that for the next meeting or two um so we can discuss when when ipsilon here and get their full opinion on it yeah sure and I think I mean also from the perspective of all cord devs like I think they would like to see that you

know the the design before and after veral how it's how it's been considered yeah okay um so spec updates we're not going to have any spec update issues um what's pending is the create transaction instead of a regular State change um adding in it container size e 7620 um return data zero padding I know ipsilon was against changing op codes and putting would prefer putting new OP codes in place um which solidity and Viper we're

like let's just change it kind of interesting um EXT with value cost um they updated some of their numbers on that and increase the call men retained gas um yeah so there's these are all all the advocates for this are not um here so um so guess we'll push these all off to next week um yes Charles uh yeah no I'm just thinking about this data section thing

now and um if you change it um to like a set data data store um that's only available in nit code then that maybe solves some of the validation issues with um E3 as well since um I don't remember the spec exactly but there's something where like you can provide less data than the container expects right so a return contract uh takes a memory region of bytes and it depends its the existing data section so that's kind of what you would get with

set data um there would be a region of data that is hardcoded in the factory and then the stuff that you would want to read would have to come after that section so there's like um stuff that is set prior to the Constructor that will never change and stuff that is set inside the Constructor and as a language designer that has some interesting implications that immutable is truly immutable outside the Constructor because I know in Java you can like turn off all your safety checks and final means nothing if you have the right privileges yeah right um yeah so uh instead of returning a memory region you use set data and get data and I think that might be

um kind of a more abstract design and that would be useful for the copy for the instead of TX cre if there is a copy create you can take the data and you could reset it yeah exactly okay that's that's the design to consider when we talk about yeah and then you don't need return contract at all uh you just ban get data and set data in or actually you just ban set data in um runtime code and then it's like actually just

part of Val code right well I mean so that would be using uh copy create in Li of eof create you wouldn't have a true self-contained Factory either uh that's right so return contract is used for EF create um you wouldn't use a return contract for TX create um because TX create really points to external init code um because that's you know copy contract you would need to provide your own AIT code that's outside the contract

which breaks some design promises you could I think copy contract should like C should like work on containers with init code in them but then how we get those nit code containers deployed everything that's stored in a contract right now starts out in runtime mode yeah I think the way vitalic was describing it is like you deploy these using Legacy transactions so we'd have some code that is arbitrarily a nit code and some code that's arbitrarily runtime code how would we validate that yeah my thought is if we had a copy

create you would provide your own init code and instead of doing a return contract you would you know end it with a copy contract I don't think you want to like have be running create copy contract with random init code right like it should be validated and like coupled strongly with the contract so another thing is you could point two um I thing that you're copying and you could specify one of the subcontainers yeah so you you deploy something with runtime code and the only thing the runtime code does is it reverts saying hey I'm I'm not real runtime code I'm just holding a nit code and your copy

container would point to an address and you'd point to a subc container number and that's how you can run it yeah I mean at that point we can actually just have like a container type which is like the point of having a container for me right and you could evolve it and you could have everything but the data section be shared and Only Store the data section with each contract yes exactly which is elevating the data section to that fourth type of memory so I think we can get there yeah I think just doing it in one step is going to be a bit too much for the community yeah

because once the code can be shared that's like actually a huge performance benefit because like most contracts are actually copies of each other right and it has huge uh just in time implementation considerations if everyone's running the same um same contract for UNIS swap you just Implement at once and you can identify easily yeah okay well I don't think we're going to get anyone who's looking to learn about eof on this call by this point surely they would have called in okay yeah I I I just think that there

there there may be some benefits to the the vitalic uh create copy of idea and I think it deserves some time to investigate right I think we need to get V Epsilon and some of the client devs in the same room to discuss it and we'll have that opportunity shortly yeah okay it probably won't ship for Prague it's probably going to ship um Amsterdam if verle's insistent that Osaka be veral and veral only yeah well if it if UF ships preal then it doesn't matter the current design is like good I think okay because I think this is something that

could totally be layered on the design without having to reboot the way things done because we're adding op codes and maybe a little bit different handling but yeah uh well we would have permanent we would have to permanently handle the UF create workflow right I mean we need to handle that anyway unless we're going to redesign how we're bring our stuff onto the container in gen onto the chain in general I think the point eof like blueprints I guess there um through Legacy transactions is like totally fine

actually uh right they need to get validated they need to get validated so there there's two steps because then then we'd also change the um developer flow workflow to use eof they'd have need to First deploy the contract on the blueprint it doesn't do any nit code then they need to do a separate contract call to actually make it live so that's another downside of this is it would increase the end user friction and would that's that's actually how Viper does it right now that is the way Contra factories are implemented in Viper no you deploy the blueprint and then everything else uh basically copies the code and runs the NIT code right but that's not is is that the only way to get stuff out in Viper

uh yeah okay because I know you can do that in solidity but it's not the only way to get stuff out in solidity yeah it's the it's the standard way to deploy these Factory things okay but what about non-factory what about plain old non-factory oh then you just do the the regular way right and that's that's where some of the some of the developers I mean in the pros you're going to be using factories and some of the you know casuals are not going Us in the factories too so oh I see what you're saying is that there's like no way to get e code on chain besides with these Factory things maybe

um yeah one way to do it is like when you deploy code the code goes into a registry somewhere so like when you do it the regular way it also becomes a factor contract um but yeah let's sleep on it yeah okay any other questions or comments before I close off the recording all right everyone gets 26 minutes back thank you thanks everyone thanks Dan