EOF Implementers Call #56

Transcript

all right good morning like good afternoon if that's where you're at or good middle of the night even um this is the 56th eofm bl's call on the 21st of August 2024 um nothing was put in advance on the agenda except for a few items from last week that I just put on which should be a surprise to anyone um so we'll just go through these as we get get to them if there's any other are there any other items people feel we need to talk about that aren't expressed in the standard ones or the fuzzing and devet forbit stuff okay if you think there's stuff just drop it in the chat as we get along um client updates I see The Usual

Suspects um another Minds uh here this week as well um basally ev1 I don't think we have anything exciting to talk about ev1 do you have anything uh we actually found the back in in in in header parer uh today so that's one one more thing coming from farther what was bu uh ev1 accepted uh multiple subc container sections because they are optional so that they will kind of handle differently um slightly differently but uh so you could put like all three as

the subc container section in the header and then another one and so header would kind of part think it's complicated yeah I I totally get what triggered yeah yeah I I I we we we couldn't find a case where that could be exploited but it's definitely serious issue um but apparently fer has not found anything with this back end that even one would consider uh fully fully valid uh us right so maybe it's possible to construct some but it's pretty

difficult um so I think we we didn't approach it more uh but we'll have a fix and some some test cases but yeah okay yeah probably finally hit the dup at string and hit the right value after a week of fuzzing I mean that's why you just let the fuzzers run so so so because I mean this something I maybe I'll try to address right it's uh it's not directly that the father has found it it's just I I was implementing fuz a mutator for for the father um ah and apparently the mutation

was kind of of going wrong uh according to the like my assumption and I needed to man inspect some examples that were kind of broken and then I found it that's why I I I don't see that's why I I say we couldn't find an example that would be if you consider howf would be considered it successful on evm side and like obviously wrong on the other side but maybe it's possible um and I think weakness of this fing comes from the fact I only compare like the Boolean value of of validation

um not like specific error codes right so uh I plan so what happens if multiple error codes trigger on the same one I mean is it a fuzzing failure multiple clients get the correct but different failure reason well you need to kind of handle that in the code somehow um I have some idea how to how to yeah I mean so what I want I have in mind uh for like s semi standardization would be instead of individual error codes uh I want to have some kind of error category so for example like the error comes from like invalid header or like a

specific code section that would be like difference and I think that would help like to distinguish what what different implementation think about code but I I will write an issue about it probably for next meeting or something okay um obviously I can try to map error codes coming from different implementation but uh I didn't try to do it yet so it would be like kind of you need to to to kind of implement some rules like this error on this implementation mean it's this one or like one of these on the other one it's it's probably not like one to one match and and I don't think we want to standardize specific er codes right now

so uh I think that there some work to do here but uh yeah I I don't think that needs attention from everyone right now okay um yeah I think a couple of the bugs that fuzzing found for Basu a couple weeks ago had to do with excess data in the subc container um if the subc container was had extra data at the end um it shouldn't validate it should be a perfect fit so yeah um never mind Ben Adams do you have any yeah yeah just a question on these fuzzer test failes are they being added as test when the fuzzle Discover something are they being added to

regular test yes I have an ugly PR I'm trying to massage into something submittable where I'm getting a lot of these failures I found into new tests um typically they indicate a failure of test coverage when to find through fuzzer so yeah definitely adding tests for those cool um so it was highlighted to us that we weren't testing the uh eof tests um we've added that in but we're failing them because uh um we do a recursive validation and we um we blow our stack so we're reworking how we're doing that to to not not be

regressive um okay that's how are I also found your tests and I turned off that blowup stack test um and yeah it's there's still a few other mostly um boundary conditions I don't know if you want to just do a catch at the end or check them ahead of time that's that's another thing to to figure out but yeah yeah we'll we'll pick that up as part of the um reworking the um yeah yeah we're sort of redesigning it okay but yeah it's I've also got a fuzzer that I wrote In My Own side repo and uh nethermind does participate in fuzzing but um I guess one of the points

um you really need to be 100% fuzzing because the initial Corpus is the unit tests and uh you're going to get a lot of fuzzing findings near the initial Corpus um I don't see um W or gu or ethereum js on the call is that correct um GS got some fuzzing findings that are outstanding too as well as um some state test failures um cool so spec updates um where were we with any spec updates are we pretty much closing the door on non-emergency spec

updates is that where we're at oh sorry you got something yeah there was some um I I don't think I was on the last call but there were that open question on um some of the previous op codes has that been covered off prev upgrades upgrades like whether to allow code length and things like that yeah I think where the vibe was last week was um we're just not going to add them right now because there is an escape hatch you can just call out to regular contract to get um the 7721 to the 7 the 721 and the 1155 um you can make a

booster contract that will return same with ext code copy you can make another small booster contract to call it um and one of the the philosophies there is once we put it in we can never really take it out again so we're airing on the side of having the option to change it later and one of the reasons I think we're also airing towards not putting it in um is it's leaning into the future of account abstraction where everything's going to be a contract uh there are no eoas so checking code link isn't isn't going to get you any information because everything is a contract which actually helps out 11:55 and 721 um because they'll try and do the calls they need

and the calls will fail so that will actually help out in that World um as far as the XT code copy um there is was discussion for EXT data copy which is something we will probably revisit once we ship this first version um I think that was mentioned on Twitter um but I and I think we were against changing the um there wasn't enough consensus to change the return codes was another option that was discussed but it we never developed consensus around it so we're going to stick with what's in there so that's the say of the spec is we thought about it and we don't feel we must change it so I think that's the mode we're in right

now can you go over again um how the gun abstraction thing helps 721 and 1155 you said something about you will make a call and it'll fail right so the plan is um if account abstraction gets their way um this is one of their not C this is what the current plan of record I don't know how soon it's going to be um but when they enshrine account abstraction every single other account um that is an eoa will get an account that looks like um it's uh the acent behaves with 721 with with with EA validation um they'll put a contract in there that'll read the signature validate the signature and

approve it and return it and accept transfers um but because it's a contract if you call it with one of the functions it doesn't understand it will return failure um so that's one of the changes they're looking into for account abstraction um but you know that we might look into you we have more time to discuss it and talk both sides of it um I don't know if we're going to do these in Osaka or Amsterdam um but eof version 1.1 or whatever we call it um we're going to start looking at some of these minor addition changes that don't require breaking and one of the candidates is definitely is contract SL EXT code size um EXT data copy is another candidate that we're going to

discuss um and I think those are the two um biggest things that we pushed for complexity reason um because we don't have to break anything now with them I mean taking them out is where we need to start out with but putting them back in doesn't break anything per se so that's how we came to that position okay so I just want to say like from the perspective of authoring a library like a solidity Library even though it it is technically possible to to do the escape hatch it seems like you would need to hardcode an an address for the um auxiliary contract that does what you

want and so there's yeah yes so the address depends on on the Chain there is no reliable method for deterministic uh cross chain addresses um so it's just like really it's deployed to most l2s there is a a L2 create 2 deployer that's on most l2s the minimum one there was an EIP for it um let me see right but it's not it's not solidity it's not everywhere that you can do solidity so or ev even so it's it's just like it is technically feasible um like I don't know if for example open Zeppelin would would be

able to use that technique and so it would there would be contracts that are like not eof um compatible and so like yeah I just it doesn't seem like a good near-term future um and personally the account abstraction argument I don't find it convincing either because like I don't I feel like there there are no concrete plans for that yet and and it could change a whole lot so but I don't know I just wanted to get that opinion on record at least okay um Ben you have something to yeah for like a booster contract you can

do the self signed um transaction from like an unknown address and then deploy that to get the same contract address from every single L2 right but I think the concern there is can open zeppin count on that is that a quality gate they want to put on their Downstream users yeah and it would be a new uh thing because there there's nothing like that already so this would be a new decision to be made the method that you just mentioned it's not 100% reliable either because you you have gas um numbers in their gas prices and

um but it is true that there are these factories deployed in many places yeah because the factories you can you can just call um I can't find the uh the default address for some of these but there are some where you call in it does a via create to and those were deployed by it but because the gas differences it might need to be a predeployment e

uh just only is contract the one of the slight issues with not having an is contract is a lot of the uh was ITP 6 18 don't remember uh the supports thing where you call into another contract a lot of those have the short short circuit where you know they test con whether the addresses um a contract before calling it so you know is this um an nft sorry is this a contract that doesn't support receiving nfts there like a St ERC standard for that and you

generally check whe whether it's the contract that you're calling first before you ask whether it supports the make the call I know I know what you're talking about I can't remember the number off hand is it is it a finalized one uh well it's in it's in the nft contracts um but yeah um because I have you know do you support receiving this um so if it's an EA you just send them the nft which is the is cont test and if it's a contract then you query the contract to see whether it supports um doing it but I mean that's

more of more of a gas thing than anything else it it's it's go ahead I think it's it's like it's not really gas I think it's part of the transfer semantics um and I think that's the main motivation here that we have found to having this ability right and it's like it's built into 712 the main nft stunard 72 oh sorry 721 721 yeah they takeen

receiver 165 there was a six in it just to be clear it's 721 does not use 165 for the support nft support detection right but lots of people will be using 165 outside and inside and they want to make sure it's uh you don't really need it for this for this RC you don't really need

that cuz you're going to get zero bytes return data so it's just going to fail to check anyway and then okay then it Bec comes a gas thing for sure yes the optimization but that can be admitted so um maybe like if if I was to make this decision I would like to see like a whole explanation of how exactly the the AA argument goes um like because we assume this will happen then um we want this outcome in the in in the immediate next heart for right

too like is it that we want contracts to start failing so that the Community start doing something earlier before the transition to AA or is it like what exactly is the argument there I would like to to see that stated if I was to make that decision okay all right

yeah I think there I think most of a lot of like the key um ipsilon people are still out on August Vacations so I'll bring this up in the chat room as well okay code go ahead on the eth R&D Discord yes it would be in the evm group okay and the other spec updates is that the hottest one out there are there any that aren't as hot that we should discuss

okay testing updates so testing is um reaching a very important Milestone here coming up shortly um on ACD last week uh eof got slotted into devet 4 by devet 4 what we really mean is devet 3 is 7702 and however many other Dev Nets they need to get it right and then the next feature that's going to be put in the dev Nets is going to be eof which um assuming 7702 Nails it on uh devet 3 then devet 4 would be when we would be in and that was at least four weeks from last week so it's at least three weeks from today as soon as 3 weeks um might slip out if 7702 slips out but we might

be looking at needing to be ready to get at least a couple of clients up there um within 3 weeks um so I guess the uh the big thing that's coming up is we need to start doing what's necessary to merge the rest of prag in and seeing that we can um activate it um based on activated straight from Prague I think one of the first steps is just to make it the test default to bra

um right now the latest release that we have it contains both e on top of Cancun and on top of PR but I think we should force that the next releases only ship from PR um just to make sure that the rest of the clients are uh up up to date with their branches of eof on top of BR um so right now the brag releases for E they are like uh this extra Fork um but I think I think we should first of all start with the tests uh now being filled with prag only so no no

more PR EIP 7692 just PR and that should activate UF on tests um yeah for upcoming releases um okay and that'll start next week's release yeah I think so I I first wish to merge 7702 tests uh make that stable and then we can start working on on top of that uh uh uh working version of 7702 tests we can just start working on uh migrating everything you have related into PR but I think that's going to be extremely easy because it's just a on

line change um what also what this will activate so right now with 7702 tests we have I I have been uh very careful to also consider eof into the test cases and the nice thing is that um with uh basically parameterize all 7702 tests to also fill under uh under EF uh uh smart contracts uh what this means is that once uh EF uh uh the the test or uh for PR includes UF all of these 7702 tests will automatically update to also fill

uh for EF so that's that's that's that's a good thing uh um but yeah I think we can do this once uh 7 702 makes it into the into into the test uh execution spec Branch uh sorry Main and then we can start working on on just bringing EF and making sure that all tests fill correctly there are no issues and if there are any issues I I will just try to um uh yeah just just fix them to to to to get the UF that's ready okay so yeah that's probably a big thing that we need to be aware of it should be I mean yeah I think every client will need to support do some

change because we've all got our custom forks for it um okay anything else from the test team that we need to be aware of and ready for maybe just that there was a release uh last week but uh it doesn't contain anything major it just contains both uh uh prag and Cancun uh really uh fixtures but there's not nothing of Highly re relevant from there um yeah I think that's that's that's about it okay

so as I mentioned earlier we're also doing you have container fuzing um evm one has a fuzzer um Basu has a fuzzer um but I think the one thing that we need to be sure of is we only get the best results if we pass all the e tests um because the at least in Basu and I expect in EV M1 um the tests become the initial Corpus if you're not familiar how fuzzing Works they take stuff that works and they mess with it until it doesn't and it's going to get really close to the ones so if we keep messing up broken test we're going to get lots of signal from the broken tests um but my results line up so far with ev1's results um Basu GE an evm 1 um can

run long-term fuzzing um without any uh without any differences or changes between any of them they all pass the same they all fail the same um for Basu um the the fuzzer only generates a valid eof about onethird of 1% of the time 99.7% of the test cases are invalid so we're really getting an exercise of all the code validation shortcuts um we also need to start up and this is something I'm going to start writing up hopefully this week EF execution fuzzing um and what's going to be

difficult with the execution fuzzing um is invalid eof containers provide zero value to the fuzzing because we're actually needing it to validate then execute it um I'm not expecting we're going to get a lot of hits because there's already Legacy fuzzing that goes on uh very regularly um Martin and Marius um keep it running in the background and they always pinging people when they mess up up their new releases um but the uh um because we're exercising most of the same operations we get a lot of the same coverage but there's operations they don't cover anything that's unique to eof won't get coverage um stuff like the data operations uh Swap and dup in

exchange so those we need to get um into some some execution fuzzing and I'm going to look into this week to see what it's going to take to build a guided one with Basu um I might just fall back and build new generators on guidos um I'm not sure what I'm really getting into on this um anyone else have any experienced writing execution fuzzers are working with them Epsilon um I have some with go evm lab um I'm also in touch with with Guido but I never actually tried to run this one yeah I mean I'd like to get it to where

it's Guided by at least one or two of the clients I think we'll get higher signal that way um because at the very least um when it's guided if we get a new hit that everyone passes that tells us that maybe we have a um a new uh bug we need to work on so a a new test case okay so I think those were the ones on my mind um with anything else anyone wants to bring up PO do you still have your mic on no no I just want to a remind that we can

we have the testing Matrix that the clients can uh confirm or fill out it's right now is pretty um um bad guesses so if anything's off there please uh um would would there be any interest in an automated form of this where all the clients have their current test run against it um against the current EST tests would there have be interest in that um I don't know how if that would not be Overkill because it's not only is it's

also they more manual or informal testing like the vm1 exported test yeah um so one one one option could be that we run a hive um Hive instance uh we have a consumer uh in Hive so this called the consume engine and basically just runs the uh consume engine um um command that we have in East it just sends engine API requests to the to the to to a running client in Hive so we have this uh this nice you HTML page where it shows all the

results um the problem is that we have to first set it up and the second thing is that it won't test so I think I think a lot of the tests are container verification so most of them they are not filling into anything uh in in in in this consum engine format so I I think we we we are missing a lot of of coverage even if we run this automatically so ideally maybe it's setting up some CI in the in the clients I think but yeah does it run eof tests yeah the so yeah so the consume engine will not run UF tests because uh it it

consumes directly using the client so it's basically spins up a client then with a certain Genesis and then it fits uh engine new payload andine workas and all that stuff so it only works with the valid um execution uh UF tests not with the container validation which is I think is a big chunk of the test that we have um so I think yeah the leci on the on the on the client side would be better still we can set we can set up high if if that's that's that's a plus I think yeah um because I mean we'll get there as part of the release process

anyway running these tests on hive I don't know that we need to push it to the left any I don't know we'll see I've got some scripts I'll post some of my findings from the scripts I'm having problems getting the number to match up different the different clients and test tools some of them test all the subtest some of them don't and the outputs are all different but at least when you get failures you you get a good signal there that something's failing you might not get the count right okay anything else e

um D you mentioned that uh you're working on the making proper test cases out of the cases that the father found is that correct um I have PR on the side yeah with some of them but not all of them that's the pi to East I presume yes okay can you post the link because we were also discussing working on sub one point so let's not duplicate I haven't posted a PR yet I'll get that out here before you start work tomorrow for sure right cool uh so also if anyone's missing a review I think I've left comments on most of the op PRS but if the there's any outstanding PR

that doesn't have a review and needs a review for me please just pck me I will try to get to it uh it's just that I've been very busy with 7702 tests uh but yeah just please bear with me ping me if if anything's missing from my side cool yeah thank you all right if there's no other last words I'll give everyone uh oh sorry go ahead it's okay I I I have another comment on on spec updates so I what the other issue I had raised uh over a month ago was the the thing about delegate call and how it

reverts when they calling to non eof contract um and there this may introduce a new kind of risk of um breaking some proxies anyway um I'm I kind of understand the rationale I might be on the camp of okay let's disallow that but there so the question would be like is there a way to detect that the delegate call I'm about to make will fail um or that this address that I have I'm not going to be able to delegate call to and so we had discussed maybe that that

um it could be possible to use x the xcode hash uh op code to detect that by simply uh seeing that the Target that you are um that the address that you have is an eof contract um so that was like one of the benefits of re-enabling the EXT code pop code um now I understand you know the the concerns with that so then it would but I just wanted to raise like the same concern of like if you want to use the sort of escape hatch uh booster contract that you mentioned we sort of have the same concern for Library authors so I feel like it's a similar question um

right in the end what yeah what's the what was the current Vibe about that issue in particular mostly I think we're in a process where we need to gather more information make sure we fix it right um and information like this um would be useful and then when you say make proxies you you say eof proxies or Legacy proxies and eof this would be only eof proxies we we've already talked about this by the way just I want to document it this is their case where someone updates uh previous implementation to a legacy implementation nef proxy

okay um yeah I could write it down and post it somewhere that would that would be good um because this specific case would help us make sure we get the thing the issue right yeah one question I have um 7702 delegates do we care does it matter should they should they be transparent oh for EXT code for for and for for proxies are we okay he if we proxy this is probably a little bit out of eof scope but we may as well fix it in eof if we're going to fix it would proxy contracts care if they call into a 7702 proxy I don't have a strong opinion but

um I don't see any reason why they would behave differently in eof to to Legacy right so you mean an implementation of the proxy would be an EA with a with a delegation set via 7702 or is that useful do we need that do we not need that do we just go ahead and go with what they intend which is it looks like a contract now for all purposes yeah it sounds okay to me weird but it sounds like it it would be very

weird because that would allow the implementation to vanish or just change arbitrarily after the eoa signs another set called transaction so it doesn't but that's not ANF concern um that would be something we need to bring up in the AA chat room and you know proceed at your own risk Ben I'm just I'm just thinking is there a situation where you could be proxying the other way so the EA was in E and you were going trying to proxy through a legacy contract so the uh the 7702 wouldn't work if that makes sense in all search

whereas I assume you'd want to encourage people to use eof contracts for um 778 okay I mean there was talk of requiring eof for 7 702 as well that's one thing that was seriously discussed at one point I'm not sure it's entirely dead um but then would that be a problem if your eoa tried to delegate call into another contract if that makes sense that's Legacy right and that was debated whether it was a a feature or a bug and I think bug the bug Camp W out so so that's why it's not in the spec okay that's fine um but as far as getting rid

of the delegate call um I'm remembering something with the seven 6780 rules um this self-destruct still operates if it's created in the same transaction so even though self-destruct is nerfed it still has visibility in eof um it's just not as common a case so I think that's why the delegate call ban is still in place yeah I think that was one of the main if not the the most the strongest reason yeah yeah that's the reason got put in the first place and 6780 didn't change it enough that we can get rid of the delegate call okay so I can write this down um and share it somewhere to to get the

most visibility possible because I have written about this before in The Magicians Forum but I feel like that's not maybe where the most eyes are so you can just tell me where I should share for the most visibility it would be in the Discord e R&D evm Channel okay and that entirely opaque sequence of Discord numbers is where it's at that I just posted in a chat thanks okay um any other issues people want to discuss before we end the call okay um next call is in two weeks same time acds next week um appreciate everyone's work putting into this uh

let's try and get those tests up to 100% um so we can get get a good couple weeks of usz again before we shift over to the Deets all right talk to everyone in a week or two bye thank you very much bye