EOF Implementers Call #42

Transcript

cool so this is uh the eof implementor call number 42 um like to welcome everyone here um so this call is occurring an hour earlier than typical um we decided to move back to Daylight Savings time instead of GMT um looks like we lost some people but we gained some people it's just getting meeting times is hard across continents um to our typical agendas we go through client updates uh then we go through um go visit spec NE compiler updates spec updates then testing updates um so Charles is here we'll get to him with compiler updates uh as far as client updates um like I said Basu

has the spec implemented um I'm going through the uh reference test as I find them and bring them in um making sure that we're up to date in agreement with some of those um when we get to testing um talk about some of the things that come in with um execution spec tests and uh yeah so that's that's the status of Basu um I think I don't see reth I don't see NE mind Marius do you want to speak for G any updates sure yeah so um I kind of took over the implementation from uh met um last week and I think we had the first four upcodes implemented

so I implemented the 16 others um this week and I'm almost done like the implementation is kind of done but it's probably horribly broken um so yeah I'm I'm still waiting to build up some courage to run the run the current tests against it to see what's uh what's broken and um yeah I don't know like generally in the specification wasn't wasn't super clear at some points in my opinion like it was it was it was okay it was

understandable but um in some points I was like okay like yeah the the spec says something like we do it the same way that this other up code does it and then I just copy the code from the other code but if that's really correct or if there's like edge cases that that aren't handled properly um I don't know so yeah I think if this were to move forward um I think then there needs to be some more work done on those specs so to make sure that everyone can can easily implement it yes otherwise

I'm I'm kind of I yeah from the spec wise I I should be done the validation code isn't isn't perfect yet it's some old thing that that I inherited that I need to spend some time cleaning cleaning up again but um otherwise yeah should be okayish yeah the um the stack validation um you'll definitely need to take another look at cuz there's significant change there at the request of the compilers to um go from for stack height it's a range of Heights or an explicit height and there are some rules about forward references and detecting dead code um the tests in uh the eof section

of the reference tests they do have a lot of tests that generally speaking hit um almost all of the corner cases and when they don't hit the corner cases we need to identify them and write new tests so it covers a lot of it um it'll it'll tell you if your ball Parker have high off and my experience is one fix will like you know knock down 100 tests at once because they're testing the same thing 100 different ways so that's that's kind of been my experience updating it from Shanghai um so we don't have anyone from Aragon here I think that's all the clients know ethereum JS people okay um so next on the agenda is compilers I think I see Charles uh do you have anything to to add

uh no updates uh from the implementation side okay um is there anything you need from the eips or the specs to uh improve your implementation of Viper uh that's a good question um I think we should um move forward on the innit code validation to be honest although it's not a huge deal I think it makes the runtime spec a little simpler and um yeah I mean those those were the rules about only one return data or

create cop code referencing a subc container yeah euf contract euf create versus return contract okay so one question I had was for for the compiled teams was um right now we have three op codes that kind of do the same thing in my opinion um the swapn uh exchange and Tube n wouldn't it be possible to get rid of cube n and swapn and just have exchange and um you can do the same thing with just exchange and one of the

dup up codes um so I think solidity really wanted um Swap and and uh I proposed exchange and then there's like different variations that um basically give you uh code size trade-offs um depending on how many like you can expand and the range of immediates for exchange but then you get a lot of code size regressions or nonoptimal code size um I think the best thing honestly would be

to have uh variable length immediates and then you could just have um swap in or exchange you could just have exchange actually and then which immediates uh which stack items it swaps is like uh kind of unbounded uh but we didn't have time to get variable length immediates into the spec okay and Andre in chat said that uh is confirming Daniel's request for Swap and dup in and um there was there were variants

with like um like there's a lot of variants of swaps which um basically can improve code size for compilers um like a specialized swap 2N up code might be like could help save some some some fights or something um and that there there was a variant with like exchange one and exchange two which like took different numbers or different size immediates um but eventually we we

shaped it down to just Swap and and exchange um so usually we do a just a round like I said up of what took place and then we do discussions I would suggest that maybe this particular question we could move to the discussions because um yeah we have been debating uh uh this C for quite some time um yeah so that would be in the spec updates we already have two items listed in Spec updates um trying to remove the regular State change uh option for create that doesn't involve that um and a container

size definition and testing updates um are there any other um points of discussion we should add to the agenda I guess we're setting this because we've done the stand up we've done the stand up for the teams and the compilers um maybe test should get a standup but that's a deep discussion that's going to possibly go along want to make sure there's enough time for everyone to get their issues in so are there any other General to set the agenda requests for subjects in terms of the spec updates I think we can mention that the the eaps are now aligned with the meas spec so up date there's some minor clarifications

to the 7620 which is the creation um but um there are mostly wording changes in the pipeline right now and all the others are aligned with the meas speec and we almost have the meta EIP to it's it's now there's a PR to add it and I don't know what's the fate of it I've been having problems with getting new stuff added as well new eips I had that um address Bas extension it sat for two weeks I asked for feedback and then they asked for a dramatic change and it's it's frustrating that it takes a long time to get a new VIP in so hopefully we just need to Ping him

again um because one one thing that was on my tier list was the address Bas expansion which involved the change to the balance off code and to the call series op codes to um in this spec if if the high 12 bits 12 bytes of any data in it to do a revert for now rather than trimming it um that may or may not get in but it's not even in the IP yet because L the editors haven't approved it okay so any other spec updates for the round table any other St

huh sorry not for me okay um let's do a quick round table on testing how's how's the testing work going what do we need from testing what does testing need from us everyone it's Dan from the t Team hi Demetri do you want to take it here testing team but might be a little noisy here um so uh currently up until now the testing was done in the test report using retested and the special tooling provided by the clients

um that just simple tools that receive cees EF bite code and returns if it's okay or not accept it or not but the main problem is that um such test contributed in a test reer uh they just bite codes and that EF bite code is generated somewhere else by um test testing tools developed by client developers in their own repositor and then they provide the test so the whole idea is is not working here because the is somewhere else and we want the source to be in the test and now we merging migrating all the tests from the test reer into the P specs using the python

scripting which significantly allows us like it increases our capabilities allows us to add scripting to the sources and the idea we have in mind is to just make also such thing for EF so that the code that currently used to generate all this e by would be in a p python script and then then by running this python script with from ppec repository you can generate all this test vectors in Json format you can execute it you can even generate a blockchain test format and executed on hi or you can use um different client tools to verify how different clients passing

this test and and so on and so on currently what we working now is this python implementation uh that will be used to generate the test and migrating all that we have currently from test to python okay so what are the asks for um the eof implementors for the tests to you start using execution test specs for our Target yeah we're very close it's still in beta and it's not merged it's nothing too complicated um we already in touch with pav from E1 team he offered to migrate their tooling from C++ into P

scripts and by using that I hope soon we're going to see first python test developed for EF and once that is done we create examples and would ask other teams who develop testing for EF to also use python form so that from you it will be required to just set up the PPC framework and see how it works and just generate the test using p script okay um because I see the PRS out there um yeah I guess that was my next question for contributing to it um are

those Frameworks suitable to start contributing tests because we sorry please go go ahead Demitri at this moment we are still in development that should be ready very soon just um yeah we need to set up the workflow and make a documentation and examples of how you can just write it um you have test in Python I guess one question I have is um because we've used python spec tests uh for like the P Fork um is is the blocker because we we don't

have like the basic eof testing uh infrastructure in the python test and you know if we're if we're going to test like the the more recent eips we need to have imported the tests for like the previous ones because they're kind of dependent on it um or is there a way that like we can test the later eof eips which don't have uh ethereum tests test Suites for them directly because we can just go ahead and write them in the Python's test Suite just like we added you know any random op code in the past Fork um see here it depends on EF like a level of complexity that the CIP

introduced because we plan to develop some structures in Python that you can use to to describe EF code so that the test will look more descriptive not just the bite code it will it will be readable structures like a normal source code and by executing those structures it will produce the bite code which you can then execute on your custom EF verification tool like this is an idea for example for now that using ppcs plus EF tool you can generate and verify your test so if if you introduce them minor change like if you just want to test white code inside container that shall work no problem but if it's

something severe which affects the structure of EF code itself then you might need support from P python to change those structures I see okay one question I have is code validation testing we had um at Shanghai there was a fuzzing uh interface written that all it did was validate whether the code was valid or not it didn't do any execution um is there any support like that in the current test spec or does that need to be added you mean just for E right currently all all the EF tests they verified by ef2 so it's just valid or

not there is no deployment test for now in a test report okay what what is e tool can you elaborate on that uh EF tool is something similar to transition tool but is very simple it's just very F EF bite code provided to it so it takes one argument which is a bite code EF container and it's making analysis of this code and just return is it valid or not and if it's not then what went wrong what is the exception maybe it was where is this specified is it implemented anywhere or is it just a spec implemented by even1 and yeah I don't know actually how

many clients implemented it one is the main one I think you guys mean exactly the same thing that's the validation tool um that we specified or before and um it's also implemented by G so we have it as well okay in the future we plan also to verify it by trying to deploy transaction trying to deploy container making a blockchain test and executing it using existing test infrastructure Andre yeah so to clarify for the T maybe so what we've been doing so far we made

two kinds of tests one are these that you mentioned we call them validation tests and and they contain just the bite code and return whether the it is valid or not but then another part big part was regular State tests in ethereum tests repo and this is also important and this tests basically the execution of UF um so basically like having some EF contract in pre-state so like already deployed and then running a transaction on it this is also important and something that we should have somehow also in the extion test I guess if we are migrating there yeah once it's in Python format it will be just one type of a python script

that will be able to generate both validation test and deployment test and blockchain test we can do it from this this one python script okay can this still take a raw bite code because part of the tests are to test blatantly invalid Scripts yeah that's that's always possible but it's not good not good when the test is just a bite code without like if something Chang in the code structure we we cannot change the bite code really easy well but the point is to bring in a series of bytes that are always invalid and they you know we're testing make sure validation works

by doing things like messing up the version or using wrong section numbers or truncating fields that's what I talk about that we want to introduce this in a python script so that you can just describe what exactly you're trying to break in a OS structure by defining like there there is a container class there is a section class and then you can can overwrite individual bites even yet of course you can make some vectors fast generated vctor for example and provide it as ajon and just use it in a script as is no problem right right the fuzzing is really what I'm focusing on we have some um the the Python's great for positive

tests but we're also going to need negative tests in validation where things are just ever so slightly off yeah it's it's always possible it's not a problem okay so it sounds like we're waiting for this eof framework to land and then we can start contributing tests for all of the new um post Shanghai features and ped over some of the Shanghai features or um are those going to come straight from the evm one code even one will be used to verify like and I'm talking about this you validation tool that just takes the bite

code to verify it but to write it we plan to use the python script and um yeah if if the VIP changes so quick we would need to be update like updating all the structures and definition of Cs for now we just want to really that where minimum of what already exists to support it in Python that's that's my idea like yeah like right now the reason so much to show but just a little more a few days and there going to be a working example and demonstration so that you get an idea how it will look like and if you all want to see how it potentially might look like check out the ex in test such as state test and blockchain test and it

will be very similar to that uh yeah I can share also one link is what we have at this moment okay so then bug 500 it's listing all the stuff that pre-existing that's good so let's say I wanted to to help move

things quicker and contribute stuff to e to the to the ppcs where would is there a list of where the best things that start working on are so I think um if I just follow quickly for Demetri while he's looking for the link like I discussed with Mario and Demitri before and I think basically if you can just hold off for like a couple of days cool then essentially right now we've got like the O code generator in this branch that Dimitri's just posted I think um and then we'll basically put an example for everyone together and then based on that example um e implementers can also start adding test cases and that's kind of the piece of the puzzle that we don't have that we'd like to then like add parameterizes

to like a base sort of test in order to generate different test cases and I think like we'll be ready for people to contribute to that quite quickly like within a few days basically okay so hold off till Monday cool um any other testing updates that you want to share or should we move on to the spec discussions and other discussions uh there's from F codes to pass verification um there were in reference tests eoff tests um there's also some PRS I guess that's another thing I mean

because we're mostly deprecating uh retest death and moving to execution spec tests um I can point to the PRS that I've been testing against um yeah uh I'll dig that up after this meeting and send it to you write that down all right um so if there's nothing left from uh testing um let's go back to spec updates um there's two big issues

well there's actually one big issue on clarification one is to Define init container size for 7620 um does that that looks like the smaller issue does that look like something that's that's easily addressed I think it was addressed already okay so the big issue there on spec updates is um a question about how we do code initialization whether we go with one of the published plans which is to use a standard contract that is brought in Via an regular State change whether we use um the new transaction type for TX create

whether we use AIT code Plus app pending call data I think those are the three big options there um I guess that would be uh poll 78 would be the spec issue there um any other before we move on to this any other items we want to add to the agenda to discuss for spec or other issues um yes cool I would I would like to discuss whether we really need the bite code obfuscation thingy the

the sorry bation thingy that that yeah yeah that we that um code is kind of not visible to DM anymore okay the introspection Banning code introspection yes so this was probably the biggest change um between the Shanghai version and what's being planned for the prog version um this was a very specific request given in the Alps um at the Alpine thing um and basically what it borrows down to is we want to have a structure for eof

where the code is not accessible from other eof code um so there's it would involve Banning things like code copy um we need to have new ways to create the code um one of the one of the upsides is that you cannot dynamically create code within code um you also don't have to expose the code code um to it so if you were to do a transformation to the code you could still run it in other systems and have it work just fine without having to bring a legacy copy of the code um I think this is this is modernizing the evm is one one one take I take on it um because you got to go through contortions on like an

apple M1 chip to be able to have your code create code and then run it within the same process that's something that um Apple that Java net have to deal with um the just and time compilation and it takes some very specific permissions um JavaScript justtin time compilation um is another example of that takes in an in iPhones and it's the whole uh issue with I think it's called the NX bit the No Exit a lot of processors have implemented um this brings strong code and data separation um code is outside the system um is it really needed um the question is it's going to be needed

at some point and when do we introduce it as my take on it if we don't implement it in eof now then we're going to need to do another breaking change in the future to introduce this um go ahead I heard someone come off mute maybe I didn't so so I guess the question for Marius is can we get rid of the code introspection Banning code introspection is that necessary um any other

opinions so from back in the day from from introp I kind of remember remember that the reasoning was that we might want to change the code of existing um uh of existing contracts by I don't know if we introduce a new OP code or if we introduce a new precompile and get rid of an OP code or something um that we can basically hot fix patch the existing upod the existing bad code that is one of the advantages we

can do yes I think that's totally unrealistic and it will never happen and we shouldn't plan for it um I didn't 100% get your explanation about the Java stuff um I I will have to think a bit about it more but if like if it's only about changing or modifying code of existing contracts I think it's it's not a good change or it's it's not a warrant change

if there's more and um I kind of get this that it's kind of cleaner the separation of code and and and data at this point but um yeah I I I need to think about it more but um so my position was that if this is like the only argument is that we might be able to um consolidate op codes in the future then I don't think we should do it um no it wasn't rewriting that was just a convenient thing to come from it um this is more focused on like ZK proving and other systems to make it significantly easier for them to prove self-modifying code is

is highly problematic for such systems poell can you hear me actually can you turn your volume up wait wait is this better yes yeah I think actually the veral tree transition is the the point that this actually might be handy and and and I mean this is nothing that it's it's figured out yet but even for legacy codes we are thinking about doing some modification to the code somehow to to make it easy to execute in the veral

trees so um it's it's it's a bit fuzzy but I think this is one of the examples when this actually we will going to tr to kind of transform code from one format to the other and those would just be packaging changes not actually changing the flow of the code well um for legacy this is hard but for like forf if there's something that would be like very beneficial for vry execution I'm just guessing here like giving an example uh yeah then then during the vry transition this this this modification

can be can be applied okay yeah it's the same that I've heard from Gom that if in E they don't need to have Cod sized code copy this is somehow simplifies veral support of UF because you don't have to take the

entire bite code necessarily and have risk of it showing up at any time you could run off a in theory you could run off a cash or a partial cash were there any other reasons for uh code introspection that I missed for Banning it um I just wanted to uh kind of point out that the reason we kind of currently do the I mean the reason we kind of need to return code dynamically right now one big reason is to have data and

immutables and um you don't actually need um the data section for that um and I posted this in the chat but like basically like in ZK sync they have like a separate section which I guess is kind of analogous to data but it's like immutable load and immutable store and it just can't be touched after init code and that way you can um do away with touching the container at all it's just kind of like a separate store it's like analogous to SL load and s store um and it's just a separate region so that's

like another way of Designing it I guess that but would we need push would we need to push that into the ethereum memory model yeah it's like uh you make the code simpler and add another memory region basically yeah that I mean I get what they're doing my concern is it's I mean it's still work that'll have to be done and we're just moving around to a different part of the spec so that approach wouldn't remove any of the problems it just changed where we would address it it might make it simpler in some cases you know it's like changing the point of origin on a math problem might make it fundamentally simpler um but the work doesn't go away because we still have to change the point of

origin yeah I I don't think it uh removes the problem it's just a different way of architecting it yeah um so kind of a tangent on the removing code introspection there's two other um in addition to Banning op codes which I guess is a a fourth item there's two other big important breaks that um are coming in with this one is Banning gas introspection and the one I want to add which is to add preparation for address space expansion and part of the philosophy for that is these are breaking changes that break the previous behavior of the Legacy VM um and if if we do it every time we break it we would need to have new incompatible version so

another request made in in Austria was if we're going to break things we should break as much things at once as possible so we don't ever have to do this breaking change again so that's part of the philosophy between um removing the gas op codes and replacing the three call instructions with call instructions that don't accept gas is that we can do gas introspection and that also would be the philosophy between behind updating the balance and call Operations to for now require the top 12 bytes be zero or exceptionally Hal so that gives us the space to when we do um if we do um create use utility for the upper bits of the address um that we could use them whereas right now by by evm speec um

only the lower 20 bits are kept the top 12 bytes are shaved away lower 20 bytes are kept the top 12 bites are shaved away and we have a commentary from some um some smart contract users that they depend on this Behavior so we can't just change it retroactively um self-destruct is B recreates one of the processes I it has some Speed Up Gas golfing with taking stuff out of Avis I think is the big deal if you don't have to mask up the top 12 bytes and you can rely on the op Cod doing it you can gas golpa waste and values uh metamorphic contracts

are gone because we got rid of self-destruct yeah I saw that in the chat that's that we're also getting to self-destruct in general in Legacy so um yeah I guess that's about is we're just getting rid of self-destruct entirely and just not dealing with it um any other comments about uh getting rid of uh code introspection and getting rid of gas introspection how do people feel about

it thumbs up thumbs down from the compiler perspective it means you can't write a jit compiler inside of the EV but otherwise we have no need for inpection and I also think that's the point is to make sure you can't write a jit compiler inside the evm yeah I'm I'm rather okay with with this

like understanding the main concern is the complexity of the change right there nothing really this like other issues except like this makes touches a lot of places yeah it does um it even touches Legacy going into eof code um we need to put some that's that's that's stuff I understand I mean I I I I could see like how how kind of like this two words feature is kind of spreading all all over the places but are there any other concerns related to this so I'm not hearing any

um people probably going to think about this and come up with um they're going to talk about you know gather their thoughts about it and and get a more cohesive expression probably in our next week's meeting which is fine I just want to make sure that we have out on the table all the concerns um so we can everyone is on the same stage um to be able to understand what's going on uh with the remaining time I think we should move into the issue with um getting rid of the regular State change um this is something I'm advocating it advocating for um basically we would um allow the big change right right now is spec in the me

in the mega spec um the only way to bring an EF contract into the system is to use a special contract that would need to be introduced somehow either as a pre pile or as an irregular State change um kind of like the same way the the beacon chain route was brought in um I'm concerned my concern there is that the ergonomics with the tooling is going to be kind of difficult and it would be better if we were to use um and we'd also um need to introduce potentially a new transaction type um for TX create um but my big ask is that for types 01 and2 trans action we allow eof contracts to be in the input data um but they won't be in

the U in in the in the payload of the transaction but they won't show up in the input data of the init code call if it's detected to be an eof container but all data trailing it would be in the input data um so would act much like you did an eoff create with the container and all trailing data coming out there um that's um my request there any any opinions on this I know we've spoken about it in the past um how do people feel about it what do they know about it is silence consent should we just

adopt it not a popular thing but yeah we discussed it as well and I think generally I I'm in favor of um I would prefer to modify the transaction structure to get the same effect but I believe this is yeah this kind of more complicated and requires much more testing outside of evm so yeah I I think we I'm okay with the like huy huy transaction uh like the interpretation of the of the of the this whatever call data for the create

transaction right this is the main thing um yeah I I did sh some stats about how often create transactions are actually used and this is like one one in the 1,000 so it's not a lot of traffic with this I think okay because I think one of the reasons we talked about getting rid of it was concern about the code introspection and changing the create flow wasn't on the table at the time I think it was like back and forth

I I think we we kind of in the beginning accepted that um the the one of the except exceptions to this where when the code actually is kind of somehow visible is this this create transaction and you need to kind of push the the eof container somehow to the system um okay like I'm not a client maintainer so it doesn't matter all that much to me but like from the compiler perspective the UF plus call data the container plus

call data is like it works really similarly to how we would do right now like right now we uh hardcode the size of the runtime code right you have like this init code right and then you hard code the end of it at compile time and then you kind of treat everything after that as like faux call data so that would be like the most similar to what we currently do okay so um you Marius you don't get the

concerns with the uh in it creation or what's what's the concerns um no I like I get the concerns with the like I don't really see why we need the new transaction type yeah so except for if we want to support this yeah I don't know contracts that can deploy other contracts right and I think that's why why it came out like the situation like take example of a smart contract bundle contract so you

have three different user operations one of them wants to deploy a transaction how do you get that data on chain if you can't put it in call data um so that's what led us to creating another transaction where you where you attach the init code to it um so you can have that bundled you can have the transaction reordered the init code doesn't have to land in a specific init code slot within the transaction when we reference it by hash um if multiple user or operations reference the same contract um they could deploy the same init code by including it in the um in the transaction once so those were some of the design decisions we got there and the issue there is um you know 4337 type support um but that was also designed

before we moved on getting rid of gas um gas introspection and right now you can't write a smart contract uh you can't write a 4337 invoker securely because you can't limit the gas sent to another call um so we would have to rely on Legacy um so it's not a complete design there yet either um it is rub Goldberg so I guess one of the questions is is this something we should move out of the initial impementation the TX create and the init transaction and just keep eof Crea there with the containers and factories

what are people's opinions on that that would would have been my initial idea when I when I saw this to move TX create move move out TX to remove TX create operation and the NIT code transaction and the ISC pre-compile and move it to another um Fork yes okay how do people feel about that would this be Osaka or Amsterdam

or an un undetermined Fork I I don't know like it's it it feels like eof is pretty big and if we can shave of some of the stuff then maybe we can get included and um yeah I don't I don't know I'm I'm I'm I think I'm torn as everyone here between the like getting as much breaking stuff

into as possible and trying to ship it and I don't know this this the whole transaction type like other than the transaction type most of the most of the changes are very localized and the transaction types and the the init codes they they touch another layer for me right um it's the the outer outer message layer I would say um like it's not it's not DVM itself and

so just testing it is is way more Awkward than testing the other evm changes in my op but um I don't know like this this this this felt to me like the like the the feature that I could live without the most so we're running late into the meeting um don't think we can get a final decision on that but let's think about this for the next week um to change the scope of eof right now um pull out of the current implementation TX create and

the inate code transaction and the um the pre-compile contract um and add in its place the um contract creation uh concatenation solution um think about it for a week and we'll move move to finalize it next week if people are okay with it um so people have time to think about it um figure out if it's going to work for them um so so let's let's move on that in the meantime so finalize that next week or not finalize it next week if people um have concerns with it but let's put that on the table for for decision for next week um okay any other things people want to think about for the next week for

finalization next week uh the init code validation Pi init code validation okay let's put that in there as well um the requirement that um yeah I I think it's spec out in one of the PRS I'll put that in the followup notes um can can you can you sling it to me on Discord so I make sure I get the right ones yeah sure okay so for next week's meetings we'll consider those two final changes um if you have concerns about them read them over um share them on the channel um and we'll discuss them and finalize them next week if there's there's no

objection i' like to thank everyone for calling in um it's great to get uh get um participating again um I guess we need to do some more Communications to make sure that um uh nethermind and get and solidity and um W are able to attend as well as Aragon uh I'd like to thank everyone for their time and work on this thanks thank you very much thank you