EOF Implementers Call #31

Transcript

all right yeah since we are like uh 10 minutes 10 minutes late already um maybe let's just get started with a round of updates and then uh maybe by the time we get to actual discussions um somebody from Viper gonna join so welcome everyone back um to the EF call let's start with uh should we start recording it is recording already oh it is oh the whole time got it um all right let's uh yeah then you on the top on the list right now so maybe um you can okay go client update so I've been um updating the uh base supplementation based off of Shanghai

I'm trying to get it in line with where we're at I've been running differential testing against uh the create 3 branch of evm 1 um there's still um between the two of us there's still a lot of things that we don't fully uh commit to um I haven't committed the full create 3 implementation yet but there's also some other Corner cases that I think get this not yet the bases correct on that um evm one doesn't have implemented yet like um uh there are some things about crossing the uh delegate call barrier um into Legacy that should be rejected um so there's minor calls like that but the stuff that we agree on um have got us up to the point where Basu and ev1 mostly agree um a lot of the changes had to do that are changes from

Shanghai relate to U moving the container and the data kinds U moving the container before the data and changing numbers from 3 to four um since data is a mandatory section I had to update nearly all of the validation tests to fix that um the only ones I didn't have to update were the ones where the data was missing it was invalid so pretty much all of them that that are valid also all the our jump tests when we went from a um zerob based uh a one based list size to a zero based list size um I had update some of those tests um got rid of a whole class of tests about jump list uh jump table too short um since we can have a zero link a jump table of zero is maximum index is zero so that's one link so got rid of an

entire error case there but I also had update all of the jump test tests again um but after you know I worked through those two items I got most of and updating the tests um from the basic op code um interoperability evm one and Bas are mostly line uh so and that you know we probably need to update some of the reference tests once we see all the the the specification and lock it down and get it to the point we're not changing it again so that's uh what's been going on basally in the past week awesome that's that's a lot of updates any anyone have any any feedback or question to

this all right then let's go over to Nether mind I man you want to go next please okay uh can you hear me guys yep it works okay so for nether mind we actually completed a draft implementation of the spec and right now we are verifying it like line by line to are going through the up codes and the new type of transaction validation to see if we missed something and if something is wrong and uh yeah that's mostly it uh also we are up uh up upgrading our

tests from the previous version since they don't work anymore and yeah that's it um by the spec you you me the the mega spec in the UF repo right the new one yeah did you run into any any issues any complications well we found that uh what's it called exchange of code had a collision with some other op code we opened an issue and now I guess it's it's fixed in the spec and uh there was some vague points about auxiliary data and uh what's it called container recursive container validation in create 4 like does it go all the way deep or

does it stop at layer one for now we we did it we coded it to go as deep as possible and yeah that's mostly it if I find something else I'll share in the R&D Channel sounds good I saw those uh uh findings um anybody has any comments uh to Imon just to remind both another mind B that we have some State tests in test repo that you might want to try running they cover great three and create four

testing mostly but it can be just like a simple test to check how you agree or not with even one this is also I remembered something the call up codes the new ones for eof the that that doesn't have like gas limits and stuff like this do they have the same up code value as the previous ones or they will have new ones I think the plan was to have new ones I think we have space resered for

them one argument for reserving new OP codes instead of overriding existing op codes um has to do with uh ZK implementations like I was talking with some of the devs and know about Linea um it would be easier if they had different op codes so when they arithmetization a legacy um it's the same Loop because it's the same set of op codes um so the validation is a different part of the ZK verification of the code and then once the code is validated they just take the trace and do what they do with their ZK stuff and so they don't have to worry about whether they're in eof mode or not for the most part okay so they are not assigned yet there is a table in um the execution

specs that has a reservation for them let me find that for you I think we did agree on the the new numbers um end of last year or maybe actually middle of last year we just probably never actually put the numbers into the spec yeah okay so I has up toate numbers okay perfect okay nice thanks guys all right let's move on to revm uh

dragon do you want to give some updates yeah uh glad glad to be here uh yeah last like two weeks something I did analysis of UF in general just like overview what's going on and I still need to start implementing it I'm not sure if you saw um sorry saw the Paradigm post about it uh yeah we are still like I still need to start working on it so we are I am still at the beginning but uh seems great I have two questions or maybe I need more clarification about a need of the jump F function and about

potentially removing uh 64 64 part of the gas uh in the calls new calls other that it looks good to be honest um yeah I wanted to reflect on the 64th so the call the the calls 2.0 so the all those new up codes the idea was that uh we don't make like uh you know an extreme number of changes um Beyond absolutely necessary and we deem that removing the the gas field um is the most important change and then not

having the return data is something we also wanted to have um but we didn't want it to change the gas logic too much because once um once the upod goes live without being able to adjust the the gas externally um we can always change the gas logic so we could always later remove the 64 rule or redesign all of that uh once it's not uh you know inspectable um that was the idea we just wanted to minimize um but I wonder in the client implementations when you do actually impl ment this do you implement the the new Coop codes as

part of the same um uh the same Handler which does all the the complex versions of the existing ones or is it brand new helpers uh AKA um yeah what difference does it make to have this 64 tool from an implementation perspective well implementation I don't it's like different function it's like totally different it's not that uh I'm not asking about I'll ask in general but you give like good explanation like the pet forward let's leave it as it is and if you want we can remove it later because we don't have gas inspection and that's like real big deal I was just asking should we like

include it that should we include that change now I'm not sure what that change is but by just removing that gas just having like fix gas something like that but yeah I can agree with like let's do it later for now let's let's yeah let's leave what we already have I just want to point out that we could potentially remove it okay yeah I think we are we're growing more concerned about the scope changes right and this is like yet another um scope change um yeah maybe we should just finish the

um uh finish the round and during this spe discussion we can go back can uh get back to jump F and maybe also discuss the 64 tool a bit more in depth makes sense thank you um all right then someone from ipsilon um well actually um yeah anybody have any response question to dragon or the Paradigm post maybe we can talk about that a little bit later because yeah in general what I would like to mention is like the bad things about

youf but we can do that later yeah let's let's do um all right someone from Epsilon uh who wants to give the update on evm one yeah we've merged a couple of things for youf so we merged and swapan new implementations and we've merged D Solo in unreachable sections and uh so that was merg to master um create three and create four are still in the branch and in that Branch we actually realized we have a bug like we forgot to

disallow uh deploy an UF from Legacy so that was fixed today and maybe that's the same problem that Doo encountered uh so that was a fix in creation and yeah that's it I guess all right any any comment question uh all right then uh let's move on to um maybe barnab bash if um I suppose you're devop P Ops if you want to if you have any update please go

ahead uh we are basically just expecting uh a time frame we would like to begin testing eof as much as possible so um I would be curious when do you guys think it would be a good time to start up like that at zero for EF so ideally we would need at least two clients fully implemented for that right that would be like a good start yeah that would be a very good start to have some kind of basic interrupt testing I think the best chance for that we have is is Basu and nether mind at this stage is um is that assumption correct Iman and

Dano yeah we can get there um I would like a a frozen spec before we get there but you know we could start getting builds that can have that as far as interrup um I think we'll probably get more signal out of um Martin's fuzz testing um which I think would be better because I think more than a stable test net I think not getting any fuzz findings for a certain amount of time I think is a better indicator that we are fully compatible with each other but one of the advantag is the test net would give once we get the compilers producing output um is for them to go through all of the masses of solidity code compile those deploy those and wire those up in

the tests so I think that is you know the the the dev Net's going to be important for when we get the compilers outputting stuff for them to get a a test base so we're still going to need that too but I think there's another we need to get you know solidity and Viper to ship versions that compile down to eof first which we need a mostly Frozen spec for uh for def 3 you wouldn't need a frozen spec you could just relaunch if yeah we can keep relaunching them yeah yeah I mean we can do uh very basic interrup testing in kosis which takes literally five minutes so if we have some branches

that would already work then I can already spin it up in my local machine and see if we have this working but for like longer term uh test it like other clients could also just sync up maybe to a public Dev not that would that could uh give some value also okay so um I am pushing my changes I need to push my recent batch up to basus mega- eoff that's a branch on Bas that's going to have the mega eof spec um so yeah there's a branch in Bas so you could use but I don't think we'll get much interrupt right now because there's

still a lot of warts on it sure just let me know um I do think there's one other use case uh that dep net would be useful for is transaction tests and I know that you know we have some transaction tests but um on an actual Network we could just just try submitting um you know various experiments on you know the create transactions and all that and that may be something of Interest all right um let's move on to

spec updates and then discussions um ipsilon uh somebody from ipsilon do you want to give a brief update on the spec any of the spec changes uh okay I can I can give it shot and there's a there's a bunch of changes that I guess were more like a editing but there are also some questions uh that we need to answer which is one of them is already mentioned is the jump F uh so maybe you could uh start with that

although I don't have any comments on that um yeah I can give an intro to this topic so yeah after Dragon raised the concerns about um whether jump f is really necessary in this spec uh so I've created an issue for discussion in in the [Music] spec and um there was some discussion and Daniel and Daniel from and Charles from Viper CH in there uh so I proposed

how it could work in case we didn't have non- returning functions and jump jump F and um yeah note that jump F and non- return function flag are kind of a package as I see it like they they can only work together so yeah we either get rid of both of them or or we need both of them uh so what there was a proposal how we could like leave without jump F we could just use call F to the function which is non returning and we don't have a flag then this non return function will be just zero outputs and in case yeah if we want to imitate jump F in this in this design we

could use call F stop sequence and then uh compiler does not need to clean the stack before this call F so the same guarantee that jump F provides When jumping into non return function so this is a seems like a VI then um solidity and Viper uh basically described what's the use case for jump f and the use case is mostly like making uh helpers uh let extracting some shared cone among several code paths into a helper which can be either non- returning when it ends with revert for example which is like a common like handling an errors and then reverting

with different messages uh or it can be returning so ending with red F this might be useful too according to Daniel and uh basically they want to to to keep as little overhead for for this as possible because in Legacy they solve similar problems with basically zero overheads so just just doing a jump into such a like sub routine um and also possibly tail call optimizations are possible with jump F uh but I as I understand this is not something that exists in compilers this

is something like for future which can be enabled with jump F so yeah overall like this extra overhead with that we would have without jump F and non return flag like if we use call F stop Instead This is like an extra extra bite in the code which might be significant if it's used like many times in the code and also this on uh call F un like jump F consumes the slot in the call stack which might be also significant at least like this is something the compiler needs to to take into account when doing this kind of um extracting the helper so it's an extra

pain for compilers at least to to take care of this uh and jump PA allows to just just use jump F and don't think about it because yeah it doesn't uh increase return stack and another argument which I think is important is that uh so non- returning flag allows for validation to to detect the the code that is unreachable after calling the non rur function so the code after call for jump F into non return function is unreachable in practice but if we don't have this flag then this code will be considered reachable by validation this

is not really nice it's like it means yeah this code will need to be validated though it doesn't have to be but it will need to be and there might be like some errors like St underflow in that section of code and then the entire code is invalid which like is not really um a good situation I think so or like in general I think that this non return flag and jump makes this spe and makes the St validation complete design in in way so that's my view I'm I'm mostly in favor of keeping it although I think complexity is significant because this St validation around jump F and non

returning is yeah a bit tricky and also this validating that function is really non- returning when it is declared as such this is also like another part of this complex um yeah and um the biggest question that I had with KF is like is is like their purpose follow of that for colif is optimization and with any kind of optimization it's like we optimizing for the right thing is it really going to like help solid your wiper to

like I don't know few percentages to speed up or five percentages or 10 percentages they still can call ordinary functions to like do whatever they need for returning I just like question I don't know so the purpose why I'm that focus on JP is to flush these things out and I think it should come from like solidity I think Viper is not that for wiper jump f is not that useful and they can go without it I just want I just basically want to verify that this is going to be very

useful and we should include it that was yeah the main reason why I'm just pushing for like reasons what's what's going on with jump Earth in general maybe the step for for this is to to basically wait for the solity analysis to see how impactful that and after that decide if it is good or not I'm not sure what others think about I mean jump F was um explicitly

requested by solidity uh for the um basically determinating functions um Andre mentioned but I suppose if you do remove some of these stack validation requirements then um yeah maybe we could do without it um but if your question is you know where it was originating from it it definitely came from solidity as a request yeah the main yeah this good information didn't know that but the M the ask is like why do they need that what's the problem that they want to solve maybe is there a different solution that we can basically give them

I from at least that GitHub issue uh 42 they said that that relaxing some validation help them with some of the cases uh what I want to basically having writing is hey we we jump F be solving this and we are like having I don't know an amount of batter code or something like that in that sense um maybe question for this group is uh is this okay to ask uh I have do ask step over the line basically in that sense so I can explain the the original request and what is uh comes from maybe

that helps uh I think some of it Andre mentioned too um but basically it's not like a it's not a gas savings it's a code size uh issue um so in solidity you have um in error handling uh you have these helper functions generated which do revert and at least in the design with the stack validation at that time this was discussed so this goes back to over a year ago um to the Cancun was it Cancun anyway um December 2022 um version of UF the stack validation uh requirements meant that if

you would just call into any of these like uh terminating helper functions solid generates you would have to Sol would have to generate um a version of that helper function for each uh each call site which has a different number of uh uh stack uh stack height and jump F was solving this by removing any of those issues and the um solid could have a single hler function so by the design of UF at that time without jump F solidity would have have been extremely um extremely not useful um likely having you know a significant amount of the code size occupied by

these duplicate helpers okay that makes sense uh is the m main problem basic what's now about use case do they need like to do something and return from the Deb sub routine or return from like main call basically this main call they can just return from the the call just return rever whatever they did if this sub call maybe we need like different solution for that do they need basically yeah they need both according

to the both can be useful for some cases basically yeah jump F like solves if you want to return for sub routine basically jump some stack other things seems that's solvable by like the all Sal I'm not I'm just asking open eded questions and B Gathering more information because I know about history this this is the like like only a that I found like little bit not fitting in eof in general maybe because I don't have full

set information in general maybe asking Sol for more like concrete hey we need this because of this would give us more information to decide if you want this or not do others implementation like Dan or Andrew are you okay with including jump f as it is or maybe with the flag of not non returning flag I'm okay with it I I think the

needs of the compiler we going to dictate which is more important to me and I'm okay with it going either way so Alex you want to say something yeah I wanted to ask Andre if um there were like a lot of discussions on relaxing stack height validation um and that some version of that would have at least removed the the terminating flag or the need need need for that flag um but I wonder would any of those uh eliminate the need for jump F

at least for this use case of jump F I'm not sure if there's any what are use case solidity um Imagines for jump F but you know if you do have jump F I mean one thing to be clear you know if you do have uh um any of these instructions I'm pretty sure people are going to find ways to use them uh ways we don't imagine yet um but I wonder what other use cases solidity was uh having in mind for jump in be on the um basically the error handling functions yes Tech validation is related and with this new with the new algorithm that we have so the original issue that uh that required jump f is kind of solved and so if you make these helpers

as uh if you make them inside one code section then you can already uh jump into them uh and address it in this way but according to Daniel so there's yeah there's a place for both helpers that are inside code section and for those that are extracted into a separate code section um so I guess so the need for JF got less with this new stack validation but according to Daniel it still uh provides some benefits for some cases but yeah there are no num and like it's more like Daniel's intuition at this point I

guess and yeah to evaluate it fully I guess they would need to implement e first and then measure so I suppose the general logic um is that we can always pull features easily um getting closer to uh any of the Roll lights but adding new features is uh practically impossible or at least we shouldn't aim to do it with that in mind given we always have this uh chicken and an egg problem that we won't have uh really good data from the compilers before they implement it and many of the compilers are reluctant to

implement it before there's uh kind of complete spec and some indication from all cord devs that this is a this is going to likely to go ahead um so with that in mind I'm leaning towards that we just keep jump f um we get everything implemented properly so that solidity can has the confirmation that this is ready um will implement it can do the measurements and we I think we still have the the option then to remove jump f um but adding adding it if we don't have it right now adding it wouldn't be an option I would agree with that and I

would say Echo what Danny Dan said it's like solity dictates what they want that's very strong statement and I agree with that because we building them for toas their their their work um all right do we have um any other spec discussion we want to have um I I do have one a meeting related question I want to discuss in the at some point in the call um but do we have any other spec

topics uh or should we go into maybe discussing the Paradigm post I can quickly go for the spec changes that we did or are considering doing they're mostly smallish one is that the data data op codes were moved to a different section because of the uh op code conflict between exchange and data load um that's been that's been uh merged into the eof I'm going to merch the PRS for the other places where it is relevant um there are there's this other

discussion is going whether the call two quote unquote of Cotes should be also a aable in Legacy um I posted the pr to spec which kind of goes the direction that they should not be allowed but um Andre said that um Alex you should you should take a look at this or anyone else that has any feedback and um anything else I think I think those are the main points and also that I don't know I've I've started slowly updating the eaps to be

to match the mega spec and also we need the meta EAP which was requested a couple of times but I'm not I'm not uh I don't think I'm going to be writing it so if anyone's up to it then go for yeah regarding the calls um I think I lean to agree to not roll them out in Legacy mostly because of complexity of testing uh like in possible interaction with old calls with new calls and it's just sounds a bit like a separate new

project to cover all this with tests and yeah investigate like potential implications in Legacy and just yeah I would rather not touch Legacy at this point and if I think that's fair yeah if we still decide it also feels like we should Champion for it separately like mention it like on at ACD like also often because everybody forgot about this detail by this point and it feels like we might not have capacity for this but to mention what I missed the work I mean just yeah e process wise we have to Champion

it for it separately separately from EF if we want to roll it out in Legacy okay is it is it final to to to not allow them in Legacy can we treat it as such I think I think there's consensus right so I think the first pass we don't put them in Legacy if we change our mind we could always bring them into Legacy but I think there's a strong argument for saying if you want this feature you have to come to eof I mean there's no structural reason we can't but there's similarly no need that I would see in Legacy it's it's neat to say hey we could do this but I think it it would be

a faster path to success to say these are eof only and we don't change Legacy at all yeah not changing Legacy is also a principle because it's Legacy if we if we if we invite the possibility to change Legacy then we we are not making it Legacy really any way from the very beginning so it's philosophical is also probably good to leave them out okay and that's all I had I think on on the spec updates okay any other feedback or question on

specs um maybe as the statement um I feel that the a is are like 90 95% done but I think outside of this group maybe few more people a lot of people don't don't know that they think that the AIP are still like work in progress or not defined or still like still need a lot of work just saying for the the people outside of this group that we should communicate that it's like close to 95 100% not not this 100% but it's like few small details are left

to Define we could put that on the website probably makes sense I don't know something in sense okay EF are very close final are finalized and few more details are left for discussions I would say it's finalized in in sense that just details are left yeah yeah yeah I mean we can we can have a list of the deliverables on the website one of them being the measp for example which is we can Treet as I don't know 99% finalized and then theps are you know we make up a number and

then the clients and such uh it is for like narrative so that people know that this is like ready to be included y I think everybody here already has implementation that need to modify a little bit but yeah or the RM but yeahh uh in terms of testing in case we do want to do another Fork this year we do have to have like a devet up by beginner of March probably latest like EF changes

and possibly anything else on the Cs side that might want to be changed so like we have to have something something working it doesn't need to be the finalized spe because even for 4844 we had like maybe 20 or 25 different demets uh because of the change in this spec but it would be good to have uh some client releases aiming to have something ready to go by beginning of March latest I would say I think Readiness you know spec Readiness in in that terms uh I think we

reached it you know many months ago because many of the changes are you know some of them are really just edge cases or simplifying or revising with the one exception is the um uh using like Lev one 128 that that's the only like uh that would be the only change which would go really against uh as being kind of stable um so tldr if if you're happy to make you know multiple Dev Nets um there shouldn't be any problem having like a March devet in my view I don't expect to just have one

DEET let's be clear about that because there will be changes all the time and I don't expect anything to be even when it's finalized I didn't expect it to be like exactly how it is like I said 4844 was finalized back in like I think February and then there was just change after change after change so it might be different I hope it's going to be different for Eos I I I'm just saying that it's not uncommon to have a change in the spec as we iterate forward I think that's a really good

question to have something testable in basically two months um I would ask like best NE M nobody from get I think I are they fine with that RM I fine with that I need to do some work but yeah sounds reasonable that gives us six weeks uh to push to get something ready for test which I think is achievable again you know on the caveat that we're going to find bugs and do multiple test Nets after that that's properly fine but at least having being in that stage hey we can find bugs is like very very big

push another Bine I okay he's not maybe here yeah yeah em let us know if you have um um yeah a different view regarding NE mind and uh having a defet around March um well one comment about the the death net you know with this discussed it earlier that maybe fast testing would would yield better results um I do think a devet itself is is just a different signal um it's more like a read Readiness signal um you know that

we we got the implementations together so I think from that perspective um it it definitely is an important step to make um uh of course fast testing and all kinds of other testing are uh equally as important um since we only have six minutes left I wanted to very briefly discuss the timing of this call uh since now we overlap with the roll call and you know it seems like we're getting into the territory that we do have to proberly sync up if we want to meet that March deadline so should we should we move the call one hour later uh to avoid the conflict with roll call I can handle one early call a week

that's one hour later or earlier FX uh I meant later um later yeah I think we cannot really move it earlier if you do want to get Daniel on the call because one hour earlier would mean the solidity I was just just confused after what Don said but I think if it's later f with me okay anybody strongly against moving disc call plus one hours Uncle with it all right we'll update the calendar

for the next one the second question with the March deadline um do we want to keep a two uh a Bly Cadence or do we want to maybe consider weekly Cadence I was going to suggest changing Cadence I think we need weekly Cadence especially because we're missing some key people from this call I think we need a if we're setting a r a signal we need to send a um uh we need to be busy signal I don't know what the correct word for that is and I think weekly meetings would do that y agreed we got some people from all the es

possible nice um all right then then we're agreed I will ask Puja to update the calendar entry so it's going to be weekly starting next next Wednesday and it's going to start one hour later um all right we have three minutes left uh I'm not sure uh dragon if he if he addressed everything from the Paradigm post or do you want to take a the next three minutes to maybe explain some some other feedback from there I think we did the main like the bad thing that the Leist is like UF not finalized as the spec basically saying to the community it's not finalized the second thing is

basically not having Champion uh the problem is from time to time Mev doesn't have like you have get mentioned but nobody's there to respond the that's that's the only two thing that we can probably work on I think the worst case that was sorry go ahead yeah that I hear from like other people like EF implementor that don't care about EF to be in or or like to to to support their cause yeah I think the the the real problem

with you know it was three weeks ago when I was on vacation and we couldn't get someone to to be vocal about it I think that was the perception that it's not you know Champion or anything but I was on family vacation and I'll be on all the calls going forward so don't worry I'll I'll I'll Bang the Drum on it if it needs to be banged okay nice U yeah it's proba fine to other people to like Champion it or basically talk about it but either we have we need to have voice on that meetings I think that's it I took two minutes we move to to weekly I think yeah this perception um I think going to to change uh in the last minute borab

Brash had a question whether the implementations are built on top of denb um so Dano Iman yes please answer actually is what what I'm targeting mine I need to do some changes on mine but on the basis side we need to plug Prague in places and various things anyway and I'll make sure that eof is currently targeting Prague for the state test if you use the Prague word it'll go to something we call future eips but it's all wired up right now um awesome and um uh Chloe you joined quite late and I to ask you uh we have like one minute

left um do you have any any feedback any question to the group oh hi uh not not really from my side thank you awesome um all right we are just about time any closing comments from anyone all right then don't forget we're going to be weekly starting next week and uh we change the time uh it was a great call thank you all see you next week bye guys thank you bye bye bye bye thank you bye