EOF Implementers Call #57

Transcript

all right welcome to eof implementers call number 57 4th of September 2024 um as posted I have the agenda um one change I'm going to propose that we do is we uh move spec updates after testing updates because that's probably going to consume all available time I think there are some testing issues we need to discuss first um but I hope to have 20 minutes to half hour set aside to discuss just the is contract I think that's about as much time as we're going to need um first for client updates so we could probably Zoom through client and compiler updates um as there's probably no uh is there anything from any of the client teams apart from We're

implementing and fixing tests that needs to be discussed um Gary got anything from Basu no mostly just here to audit okay and um next would be gu gu I don't see on the call um nether mind anything um we did merge the uh e test CLI support cool um and let's see re anything above and beyond typical uh no everything's fine just run the latest test everything's passing so that should be it I'll be curious to know if other the clients have sport for

7702 and UF on top of it so that we at least have some idea when the UF testing or devet can be can be deployed yep we can do that later sorry yeah I think that's on the move to prog for Activation we can discuss that there so yeah we'll definitely discuss that um ethereum JS do we have anyone on the call from ethereum JS no evm one anything on the ordinary no I I don't think so okay I don't see anyone from solidity or Viper okay so yeah The quick summary is

we're getting tests ready for devet 4 which is going to be after devnet 3 um and up update your implementation matrices uh that's the Bas of ozen update we uh um tested the 14.1 they're starting to remove the big change there is they're starting to remove the uh broken and old duplicated eof tests out of the Legacy ethereum test repository and 14.1 gets rid of all the current broken tests so you should pass everything that's in etherium test that's eof right now um and uh that EO that EI eof link that uh ifon link

158 yeah so the testing Matrix looks like yeah so these two lines need to be checked uh if you implementing them um I'll get that PR in later today um so the next on the agenda um the first thing is we need to start looking it's moving into prod for Activation I guess this is a good time to discuss devet 3 and 7702 um how do clients our implementers on these teams also aware of the 7702 implementations and how things are going I think on 702 eum GS J and R is

only only passing at least that was status last week so I'm not sure if other the clients are probably I'm assuming here are Implement those okay um have we launched devet 3 yet I don't think that's happened yet has it no it should be next week I think okay but I didn't participate yeah I didn't participate in Monday's interrupt call so I'm not sure okay but the specs are locked in I think yeah yeah okay so um The Next Step I guess is to move the E EST tests once uh we're satisfied we have a good EST spec um

okay there are a few 7702 changes but they're scheduled after devet 3 um but I think it's time to start go ahead uh I think they're related to light client proposal to with invalidation of the section but those are very small and they're going to be cluded after demry okay and are they comfortable um slip streaming those into the devet where eof turns on or they going to move us to devet not sure to be honest it probably depends when the deet 4 is going to be like created okay if is right after the de Tre I would assume I would basically do

those changes after UF after devet three after devet four but this depends on timeline either way there's more changes so it wouldn't matter if it excluded D four or D five yeah okay um but I think the big thing we need to do is we need to start wiring our implementations to activate at least have a PR ready if we're not ready to emerge it yet um that is synced with your main or Master Branch um oh yes we can watch the there's a pee beneath that's being recorded today maybe we should jump on that um or we could watch it via Zoom or or uh next week when it comes on YouTube but yeah

definitely um but we need to get our either either through a um a PR off of Master main something that activates our e stuff on Prague and that'll help with tests a lot um so next thing I want to go through is I've got some implementations for um let me put this about a different tab I went ahead and tested everyone's client against the test Nets using your CI tools um so execution spec has one ready to go um and some of the one of the one of the problems we have is that some clients aren't able to um run all the state tests or the uh block tests because we

have very inconsistently named uh Fork names whether it's with Prague with eof or not Prague or Cancun um and I think that's for some of these failures definitely all of R's 11 failures are coming from and I I'm wondering if some of G nether Minds failures are also related to that mixed date um the big thing I think that gets gu that gets W is they don't activate the create transaction except for Prague and that's not what's generated in the tests um so if we can have one I think Mario linked a PR that's going to flip this over um to Prague the big change super it's super simple um so

yeah the E of fork name changes from either Cancun or uh EIP 7692 or PR with the same name to simple PR which means that uh we are going to enable uh tests that are parameterized for um for for example all the call up codes let's say uh call EXT C and all of those are going to be enabled also for prag which means that uh 7702 tests once they are merch uh they are going to be activated for this uh euf uh up codes too um and I can go over the uh 7702 tests also if that's if we have time um I can show a couple of examples of how

um when this uh PR lands into Main and also the 7702 uh PR l in Dom main we can have this uh cross EIP testing for EF and 7702 uh let me send you the link because it's not in main yet um give me a second or I can share my screen if that's easier yeah um so let me stop sharing and do I need to give you permission let me try should be able to all right let's see does this work yep I see it

all right so yeah um basically this is the main file that we use uh for 772 testing and one of the nice things when we rebase onto oh first of all the is the text size okay [Music] or yep okay yeah so one of the nice things is that once we have this thing in Main and also the we have the activation as braack set to set for UF it means that we are also going to be able to parameterize a lot of these tests let me show you uh a couple of example yeah for example this one um what happens with this test for 7702 is

that we have these markers that uh depend on the fork uh that they are running on for example if you have this this Market which uh with all create up codes it means that if EF is activated in the same Fork as 772 it means that it's going to parameterize uh this particular test not only with all the gr upcodes that we have now which is great and gr to is also going to parameterize with gr um e of gr upod sorry um so yeah you can see that we have some code already in place um it's not guarante guaranteed to to work at this moment because we haven't tested it with any of the implementation because now implementation apart from B supports uh 772 plus uh UF but this is just one

example and you you can come into this uh PR I will share the link in a bit and you can take a look at all of the uh tests that we are going to automatically parameterize for euf once uh UF and 7702 are in the same fork in main um but yeah uh this is just one example but we have many others uh so for example um tests that are calling into uh I think this is a a call into the same uh same self contract and we test with all the call up codes which is currently for def 3 is just a constraint for call delegate call and and whatnot but once again once we activate UF with

7702 in main uh it's going to extend it to the u x x variant of the of the up codes which means that's going to cross test with the UF um um yeah that's basically just um I think I think it it would be better if if you guys come into this this file and check uh this uh this this test by yourselves to see if there's anything missing um but yeah that's the basic idea so it's with all call op codes with all create op codes those are the two marks we need to look at exactly exactly if you come here and you see any test

that might need um um this markers has and and it has not applied them I I can just totally come just come here and and update tests but I think it's it's a good coverage uh to start with um I again I haven't run this tests in in EF mode because there's no no filler right now but once we have the filler uh there's at first there's going to be some failures of course because they're not tested but we we can clean this up and then we can make another release which will contain this uh cross cross EIP testing

M uh let me sh the start sharing I will share the link uh directly to the file so you can take a look there you go please please take a look uh let me know if you have questions or suggestions or right done real quick all right so let me go back to sharing cool cool

um the next issue on here is fuzzing and Mario's discussion um ipsilon do you have anything interesting about fuzzing that CH anything you want to add or that we've done with fuzzing no no I do so this yeah so I kind of stabilized the the father itself um there are no no new findings I Incorporated Java F of the kind of site um guidance tool and I didn't I didn't uh include any other implementation

because I don't think they pass all the tests right now so doesn't see the point yeah um especially because the fuzzing tends to use the um the tests as their seed Corpus so there'll be a lot of adjacent failures and it's hard to get a good signal um but once your um once your client's up to 100% on eof test let us know and um we'll fuzz it and hopefully we won't find any more bugs and then we'll be in a good position and this is for eof layout so cool um Mario also

had um converting e format tests and state tests is there anything we want to discuss here other than what's in the list so yeah I think the list is pretty self-explanatory um uh the way that we doing this is basically just converting putting the um the E container into a init code init container sorry and putting that as the transaction data in a great contact gr transaction so the uh the goal of this is to test the validation of the EF container when the uh the the client receives the transaction uh so this is another code

path that I think we should we should cover so basically with this enabled we are generating every single e of test as state test and the the test count basically bumps uh twice fold so yesterday I checked we have uh 6,900 tests around around that and now with this enabled we have 12,000 tests uh so yeah it's it's quite a bump uh but I think it's necessary because uh eventually the only code path that is going to be uh uh actually run in Main in my opinion is just the great uh the

the transaction cre creation for validation so I think it's important that we that we that we fill those tests with this yeah I'm conf confused about the init init mode I think that should be like the the easy part because the init init mode is expected in this TX no in this in this create transaction right yeah so basically um when when someone develops a a UF test that that

it contains a an a container the problem is during verification phase uh at the end of the state status because we don't exactly know what the expected deployed code is going to look like um so that that that is basically the issue U but I think one alternative that we can do is point uh in the second bullet point the B option is that these init containers they need to specify also apart from the the the container contents itself they they also should specify how does the um how does the uh deployed container look like so if the test specify something

like this we can actually verify the deployed uh code code at the end of the of the State uh execution okay I got it I think I slightly like the B option more but uh okay yeah I I I think it's a little bit more more work um so this this deploy container is not going to end up in the E of test fixure but it's going to it's going to be significant for the stat test it's a little bit more work but I think it's worth it um because we have a one toone conversion in this case um yeah oh there's also not like this a lot

of you can do with this uh with this runtime container right it's it only differs in the data section so it will be one of the it's kind of expected to be one of the already subcontainers that exist in the code and you can only manipulate the data section so I think maybe it's also Worth to just try to like fuzzy match if the other parts are the same but the data section kind of ignore for now and maybe specify it um as the expected data section something like that I I would need to also take a look and like in practice how difficult it is um so do you mean like um appending data

sections dynamically in the D option you have like in it in it container as the kind of the main thing of the test but you also want to have additional let's say field of expected runtime container that comes out of it right yep yep so you can you can check it actually this was deployed in the state test so what I mean is that this rtime container which it will be one of the subcontainers of the init container so you can kind of already you have like some information already even without manually specifying this and the only only thing the init

container can do to this uh output runtime container is that it can only manipulate the data section of it so the rest is expected to be the same but the data section might have different size and different content that's the only difference you can like there's no way to to modify it some other parts of it yeah makes sense so um so I think what we can do is like for automatic uh is to try to see if the first container is the one that is

deployed right um if not the test will fail but then the tester will have to yeah yeah yeah it's like one of them yeah that's true it's like not the first one it's like can be one of them but maybe it's it's like usually the first one and in a case if it's not or the data section is modified then you would need to specify yeah expected yeah makes sense all right I I will try to do that let's let's see how many tests fail or pass with this assumption mhm okay um any other open testing

issues any other experiences teams are having running the tests yeah you you already mentioned this but I wanted to say just this Legacy this new release of the Legacy test and I think we we done with it for now gu we should pass all of them um it's 1401 right and I think this is mostly uh the difference between the older version is just uh removed coverage I don't think there's any added coverage or fixed um there was there was a group of test that were fixed okay okay sorry okay then it's a meaningful it's yeah I

I don't expect this is to be significant actually okay so it were it they were fixed but they were just kind of on this level of examples or something and it was fixed only by this um role of um top top container right yeah so only this one and because we had a fixes for them I don't know probably for half year suddenly I didn't mess up so that's the differ there's some difference but I think there was like four or five group of test and let's

say all of them were converted to East except one group that was fixed in place and gotta okay never nevertheless don't forget to remove any exclusions if if you have this you probably had exclusions for some of the test that were in passing so be sure to wipe them out before updating I guess that's it okay so I think that that's uh all of the testing items so I think we can move on to spec

items and the big open spec item is going to be the is contract instruction um we did discuss this last week on ACD um I expressed my concerns that um if we just add more stuff that the rest of the C Deads will push back on it and the plan that was proposed in ACD was we proceed on test net 4 as is and then we consider adding is contract on a follow on test that if things go well um so to that end we have an EIP um that specifies what we would propose would be added either in Prague or in the next uh major Fork depending upon

when it gets slotted but the intent is that this becomes um the solution to the problems we're having with um 721 contracts 1155 contracts and any other contract that depends on distinguishing an eoa from a smart contract account and behaves differently based on those two and again in here the motivation we're calling out the safe transfer um on ERC 721 on ERC 1155 is our main motivation so I like to open the floor anyone that has any comments about the flow of this if this is going to be sufficient if we need something different um so yeah Ben you got your hand

up uh yeah so is my my concern with having a specific is contract rather than say um enabling length even if it returns junky data is um say let see libraries where um the they have an is contract function say that's um doing size greater than zero um and there's no detection as such to say whether you're compiling to EF or compiling to Legacy so you don't necessarily

know you know that it should switch what's being used that makes sense but maybe that's a city um thing that they could add a um I don't know a hash Define or you know if death if if this is a e compiled do this if it's a um Legacy do this it's not necessarily a bik code issue but um but certainly in terms of third party libraries they need to know what Target they're compiling

to I think many many libraries which would use assembly to that extent or you know depend on excot as excode copy would have to be changed anyway they just wouldn't compile yes but if you're say I don't know open Zeppelin and you have here's are um I think they've removed it but um if they had an is contract function and you as a Deva bringing that in um how does it know whether to call is contract or whe

to call um X code if that makes sense so is this something that solidity could add a new is contract function and they'll be smart enough to figure out whether to decompose it to is contract or the EXT code size tests um either that or solity to add a um you know some kind of if to find or whatever a conditional compilation so it could you could say if I'm compiling to eof version one uh use this code if I'm compiling

to um Legacy use this code because it it's really in the compilation isn't it whether what you're using it's not it's not not not necessarily anything on chain if you are compiling to EOS the bite code is different so it is sort of at the compiler level that it would be probably most helpful for solidity even the is contract um so on the address type there there are a bunch of helpers like this like balance. code code hash it was an issue to introduce is contract which would perform the xcode hash or X good

size comparison um there's an all sending issue for this it was never never imp mented and there was another one to expose the evm version um which wasn't implemented because the the problem it part it it has is a optimization um and the new pipeline solidity has would be much better at that um so the optimization issue if they had implemented at the time then it wouldn't remove the the Deb code path uh for any of that and so therefore it was undone but I mean these were these are

long outstanding issues in solidity and this basically comes up every single time there's a big breaking change even in the EV in the evm and I recall that open Zeppelin took at some point like a year to transition to a new version of solidity um I don't think there's really a way around that probably the same going to happen and this is for something as subtle as push zero right yeah I think open Zeppelin at least doesn't has that many lowlevel optimization so it's not an issue for them but something like Soul ad

definitely is is affected by post zero okay and Ben what were you going to say um yeah I mean I've even seen in the taer contracts they have a you know try and detect whether certain things are supported um and I think it happens on on chain I'm not sure how I'll go look at that um but it it is a it is a problem that there's no way to conditionally compile um what your what the target is you know and produce the correct B

Cod I think in Tao it's the um they use uh what's it called T store and T conditionally yeah transient storage such a simple change and so divisive yeah but there's no way to detect the you know the what you're compiling for supports um and it would be you know a lot easier if it was done at the compilation time rather than something on chain you've got to configure if only there was a header format where we could signal that we

need the new T store instruction before you loaded in blockchain I mean the solutions here just needs to surface okay so how do people feel about is contract besides those issues would so the main alternative would just be to open up EXT code size and EXT um code hash and those would address the issues of am I dealing with um um yeah go ahead Dragon um this contract does Mak a lot of sense uh to be honest I'm in support for

adding it it Sol the problem to check if the account is contract or not basically it that's the main purpose so it makes sense to add okay yeah so let's review the Alternatives um the extra argument for the EO EXT call we would have to do that now or and not do later but it seems a little overwhelming um as long in addition to the extra status code no op codes return to values currently so that would break a lot of assumptions um exit code status also um and register and so from here

reenable EX code size is something we could easily do in the future um we using exd Code size using the op code was also considered but rejected um I mean that would solve a lot of this compiler if all they're looking for is greater than zero but if they're looking for anything like they're testing in the code size of another implementation um that might cause problems um yeah I mean it would that would resolve the conditional compilation isue but yeah as you said it would be returning junk if they wanted to actually use

the Peter uh so on last uh ACD there was a mention from someone from the AA team that uh this would be problematic so I want to I want to reach out to this uh these people and and just try to get a like proper write up or just description of the problem so that we can put in here and this is why one of the sections is still at TVD okay once the dust settles and um on the CIP and maybe it's even merged and I will reach out and and try to get hold of them um by the way in the chat I link

the two solidity issues I refer to if you want to put that into the into the text down okay yeah what was the other one right I think the yeah I just

remember what the issue with the evm version was that um even on the assembly parsing level it would need like short circuiting to avoid the the other path um because with have instructions uh not supported on the given AVM okay got those added to the notes and I got the formatting right good deal okay so it doesn't sound like there's

any action to on this contract we should all review it um we wait for it to get merged by the eof editors and then we can I think the next big action is we need to have a review from the AA team I think Peter mentioned Peter was the one that mentioned he was going to reach out right did I get that right yep okay so once because I think I think AA of all of them because that was actually one of the you know arguments was like know we should ignore it and just live with the account abstraction future um where everything's going to be a contract in this is pointless but yeah so we need to get that from the a18

um okay so yeah review this and in two weeks perhaps we'll have uh some action items we can have off of this um we won't be in devet 4 in two weeks but we might be a week out so that is one thing we need to keep in mind um probably we're going to be at least two weeks out though I don't think we're going to do a solid two weeks on devet 3 I would be impressed and happy if that happened but I don't think that's where we'll be okay um any other things we need to discuss any other implementation concerns as we push towards devet 4 I wish guest would gu would call in I really think we need their

representation here okay any other things we should discuss before we end the call um what about Aragon they said they oh Aron UF um there's no one from Aragon on the call are they I don't think so cu Aragon 2 is what we're talking about because Aragon 3 which is not ready for production yet is using evm one under the covers so Aragon 3 I think is covered um it's Aragon 2 and have they forked significantly from their gu evm

code or are they still bringing a lot of that in um I think it's it's it's more complicated so Aron 2 can use ev1 but it's experimental integration Aon 3 it's go onry right now so it cannot but I think they working on the implementation but I don't know what the what the status is okay and Ben what did you say about nether mine what's the status on UF and a

7702 um so we're sort of using the Prague um test but um 7702 is in a different branch so um it's not in so we we're the R's on our Master but um 7702 is not merged yet well we'll see how it goes okay andeven will land in Master first right yes um but I'm I'm happy enough for the the test to change to only target

P okay and then we'll deal with whatever fall out uh are you running UF validation basically test yes uh okay cool uh what else is there to be done regarding UF do you need to run other test we have a three think three types test East ethereum test and evm one suit so you running just ethereum test or are you running East test I think maybe just the

eum I looked at your code and it looks like you're actually pulling the current published releases but you're not running the E from an unfilled python yes for running the the publishment the um fixtures yeah if if you need any help just ping us and at least looking at the traces around that yeah okay cool cool yeah and I guess on that we probably need to get a new set of fixtures published by the end of the week I need there's a um I

need to finish up the pr uh that's testing Legacy op codes so right now the head of EST is broken um with the EXT uh callop codes are actually being called in Legacy code which should not be allowed so I'm adding tests to make sure that EXT um that all eof codes are not call with Legacy verifying that they break and I need a finish that to make sure it breaks in a nit code and a couple of other um usage patterns that Mario wants but once I get that in I think we should probably get another set of fixtures out and published and that'll I think help speed some people up I think I already left some reviews uh for both uh yours and Peter's uh PR um yeah just let me know whenever you

want the new release I maybe maybe we can wait for this two PRS because I think the uh state test fixures is going to take a little bit more maybe only those these two PRS and then we can release yeah once one of those gets merged we can release because that fixes a a bug that I put in unfortunately yeah so uh I have one more uh PR in the pipeline which is regarding you create gas costs but it's still I Got U I got stuck with something else on the way so it will you want which number is that not yet uh not yet pushed uh but yeah just just heads up but this

will surely need to go after the release sounds good all right anyone else got any open issues any subject at all one more client we may miss tarium GS so I'm not sure how the status of those yeah yeah I mentioned them at the top um they do have a fuzzing interface so I was able to drop a few fuzzing things there I don't know how to execute their fixtures from a command line because if I if I can get how to execute their fixtures from command line I can run it

in my own uh scoreboard test that I posted um from my markdown link I've got I posted um yeah I run scripts for to run all of these so um I hope hopefully um a number of the failures from our side have been fixed on that yeah I think there's probably like maybe three more issues related to like jump F and some pricing so it should be fair it shouldn't there's less fixes than failures I would say we're getting to that part of the test where we're causing the same failure multiple ways multiple times because that's where the bugs beep

in all right uh give everyone 10 minutes back thank you for calling in uh thank you for participating in implementing it's been a pleasure