EOF Implementers Call #37
EOF Implementers Call · 13 Mar 2024 · 24:40
EOF Implementers Call #37, held on 13 March 2024. The EVM Object Format, or EOF, is a proposed overhaul of how contract code is packaged and validated in the EVM. These calls bring client teams, compiler authors and spec writers together on implementation, testing and specs.
Topics
From EOF Implementers Call, hosted by Ethereum Foundation.
Transcript
progress welcome back everyone to the weekly o call um as usual we start with a client updates but I don't really see any other clients apart from evm one ipsilon um but we do have someone you want to call Chris I'm not sure if Chris this is a person or recording AI um but if a person then uh yeah do you want introduce yourself all right maybe it was an AI uh all right then um yeah just for
the recording let's do a client update from evm one uh who wants to volunteer I can give an update uh we have merged the X code Logic for legacy targeting UF and also one piece of creation logic which is um uh disallow in youf creation from from Legacy um and uh other yeah create op codes you have create and TX crate are still on review and we are working on that um
and exchange implementation is in progress I think yeah just started okay yeah that's it awesome the other um 663 instructions those were implemented just exchange wasn't correct Swap and dupen are are already merting sounds good uh all right let's move on to spec updates maybe Peter you want to that yeah um so we have uh we have merged the update the 663 update which is the exchange op code and also um slight
refreshing of 3670 just a language update mainly and um 3540 and 7069 so the basic uh EAP and the uh calls 2.0 EIP are still in review and also in review just uh fresh um there's the 4200 one which is uh static relative jumps and 4750 which is uh functions um the first one is in review as just moving into the review status and the second one has has
some uh has some changes to align to the mega spec which I tried to get right but uh reviews are uh encouraged and very welcome on this one so that uh we can have a the EAP in good shape and I think that's it all right should we I mean just since all of us are here should we use the time to maybe go through any of the checklists what needs to be done in order to merge the EIP updates or is there anything else
pressing um we should discuss right now you mean the ones that are W thing for a while 35 40 and 7 69 ones yeah first the outstanding ones and then if uh anything which hasn't been written up yet we can also discuss that uh I think uh that is that's the end of the list so these four if I'm correct are still uh not updated I I don't think I have any specific points to discuss in those
they just need someone to review and approve I guess or was there anything specific that we wanted to discuss last time hold on yeah I think for two of them I did review but since it wasn't draft I didn't um I didn't approve to avoid merging and I think we were looking for like a second review I'm not sure if those to place okay maybe just when when you if you reviewed just make a comment and just uh nominate someone else to review or um sounds good okay thanks yeah I think this call
uh uh become became kind of empty because both um chars and Deno are uh traveling um all right is there anything else we should discuss from anyone we were discussing the launching the devet at one point and Dano updated the Bas status in the implementation Matrix and it seems only creation is missing on his end he mentioned that not maybe not all the reference tests pass or are complete but in terms of the implementation itself uh it seems that he Bas is almost ready uh to be up to spec up to me up to
the mega spec I don't know where that puts us puts us on the on the path to the defet um what can we help with uh for Deno um to achieve that are there any of the test cases we still have to push um I mean to to create them or yeah actually on the testing how are we getting on getting the test PRS merged on the test repo are they getting merged or are we
working off branches no I think they are getting merged pretty fine but our PRS were mostly fix in existing tests for New Logic in the new spec so we haven't been adding much new tests lately I would say yes same on my end I was mostly working on having the old tests uh f with the new with the new spec also since I'm I'm still a bit um new
and Confused in terms of the test Department I'm not sure I wish I could I could go through the test and and try to have a feeling which are still missing but I I don't have this right at this point maybe someone else can um can give an indication of what would be um you know what would be a good investment in in in making those tests more more complete yeah I was I was uh also
wondering about um yeah the new tests for example for this new kind of creation um for UF create and DX create uh I was wondering if uh we are going to continue creating state test for this or this will be generated by evm one itself or what is the approach we want to follow here yes so this is not clear to me either so separately from these normal tests we have now many state tests and validation tests that are generated from ev1 unit tests and they have pretty good
coverage they cover many things um but whe How are we going to merge them and whether we will merge them Upstream that's not quite clear like because they don't have sources that's uh may be seen as a problem or I don't [Music] know there are like Json tests generated directly from from C++ code andm one so yeah they cover create create you have create ntx create pretty well um so also I'm not sure whether we should like write regular tests from
scratch maybe not do I recall corle correctly that the testing team was uh supportive of having quote unquote ev1 tests uh pulled into the testing S I remember something like that but not sure what that means exactly whether we merge them into test strip or not or in what way like the easiest path forward would be maybe to generate the sources which shouldn't be difficult then we will generate the sources and then these
nest look like regular ones and maybe then it's possible to merge them but we haven't worked on that yet because right now our generation is Json yes maybe as a first step it could be just Jason and then we can um kind of work backwards and make them y yumy them um doesn't need to go backwards it's
just different things to export to make a source file and it shouldn't be even a y can be Jason too kind of depends who other who other teams who wants to use it um because we can easily generate Json test and just make an make an zip file with the tests and and publish somewhere and this is more or less how this execution spec test are done so we mostly download the just big pack of Json files and then you
can execute that um so that's I think relatively easy to do but they won't be on this a flash test then so be other source I think it might be enough for some people although H yeah there are some some issues with the format itself we could make it like a like a GitHub release something like that on evm one or yeah but but now I remember what what are the issues with like using this is that uh the status format it it hashes the the results
so so how you use it is just you need also hash your result and then you compare and in case it's different there's no way to tell what's wrong so that's really difficult to to like work with if you're are developing anything yeah could we have for example traces accompany the those tests would that be reasonable or that too big no I think then if if that's the problem I think the reasonable Solutions just output this the yo files and then uh there are expectations in this files so there's at least some source of
information and traces are possible with other tools to get as well um so yeah think something like that yeah but I meant like the traces which are kind of reference traces for for the for those test scenarios that are just at with ev1 and someone doesn't have to you know install or build ev1 in order to obtain those reference traces but but yeah outputting y would also be an option it just needs to be coded in evm one right yeah mhm I think we should get like other
clients teams input on this what would be the convenient way of sharing those tests we can do this in Discord and if and if they say yes to yaml then then we could we could just uh implement this in e all right um you mentioned
earlier I mean if there's nothing else on the testing um you mentioned at the beginning that we wanted to have the dev net and you know we need um Bas for that right another question on that actually um probably to P is silk worm still operational or they shut it down uh yes it is but it's I think it's different uh it's a bit different from what we want so um I'm not sure exactly what the status
is but like it can execute all of the like transactions and all of this but I I don't think it's like good good peer-to-peer Network participant uh I think it has some support but that's not like something that it's really really stable my understanding I thought it just needed uh Aron for the initial Sy but then it does have peerto peer it has it has peerto peer but I I never actually use that um so because like the the initial thing is is based on snapshots which are taken from from bit torrent
Network so like doesn't really get it from any where uh so you need to first of all you need to kind of make the snapshots and it cannot do it so it's I think it's a bit complicated how it works I think it's General by of Aron um uh however what they have right now is they have like combination of like Aron with with C++ execution so uh I think that that's more like realistic use case um however I'm still not sure if Aron
can easily be used in a devet if it can we can try this combination okay that would be interesting it's like it's like merch of the like let's say Aron Network and silor block execution so that is combination of these two code bases into single like product um would you potentially look into this until the the next call just to see if it's yeah yeah sure still possible then we could have um two clients on the dep
net um all right right the other brief topic I wanted to discuss is solidity um so I looked up the the old PR and it implemented uh it implemented three of the IPS so the container format static relative jumps and function uh function sections um that was the extent of the implementation um I think it's probably rather at data the branch itself so rebasing would be potentially quite some pain um but
then implementing other stuff again is is questionable um I think I can try rebasing it um but should we try to invite Daniel for the next call all right there's some thumbs up okay I will chat to Daniel and see um yeah see what happens I don't have any other topics
from myself and uh since it's it's a short call I guess we can call it today unless somebody else has uh anything else to bring up I I just have quick question about the EIP updates uh I wonder if you have like agree on the kind of more or less the procedure We are following uh I mostly like there's some confusion I think about the how the update are merged uh in this by this EAP Bard and and I think it probably makes sense to just always start with a draft Pier so it's it's only merge when we
actually want it to be done and there like some number of reviews we actually want to have uh I'm not sure but I think we don't really follow this very strictly so I wonder if you have any opinions about it I'm fine either way I mean one way is to to put a comment that looks good you know but not approve it in in the review and then someone else can review it still before merging or we can just draft all the open PRS and and just remember to open them in draft moving forward I think either way is
fine hopefully that's this is not the reason why um we are not doing the reviews no I I don't think it's that's related yeah but I agree that some of those PRS could use multiple reviews but you know technically either where either way works other um mention that it looks good but you're
not approving this and just uh find some and look for some more uh reviewers or or we can move them all to draft is there a preference that you have m yeah I think in like selecting from these two options I would just use the draft all right because it also depends if you are already an outter of a or not and like if you are then it will be merch without any reviews and so I think using draft
just works in every case and it's like more robust okay uh the call I'll just go for the open PRS and make them draft but please review them yeah yeah sure all right Peter I'm G to wait for the wait for my reviews until you move it to to draft and I can make a sure sure all right anyone else for any closing question all right then uh I think next
week going to be way more busy everybody should be back um yeah closing unrelated note um after dun I checked solidity if it implements in copy and it does um and apparently they're going to make um and it should be out in a release because it was written in a few weeks ago um but they also making um Shanghai the default canun the default sorry um so yeah Sol should have M Copy um support so that's some good news
nice all right have a nice day everyone and uh yeah see you next week on this call yep see you next week bye you bye all thank you recording stop