EOF Implementers Call #63

Transcript

all right I'd like to welcome everyone to the 63rd eof implementers call it is the 11th of December 2024 this will be the last call of the year um nobody wants to come into a call on Christmas day especially me so we're going to cancel that one and the next meeting will be the 8th of January um so here's our current agenda we're going to talk about clients compilers and we're going to do spec updates uh uh first uh EIP 87834 t about the eof metadata section then we're going to talk about generic factories and deterministic deployments uh which was a discussion request from uh fronio um and probably eof create hashing those two might uh collide

together so we'll talk about 7765 tracing changes um Laten spec updates and then do testing updates afterwards and I have some stuff to show for some of the work I'm doing on eof execution fuzzing um and if there's any other items people want to discuss feel free to add them in chat and we can get them slotted in um all right keeping up on chat all right um so first clients uh updates and compiler updates do we have anything from um Charles anything from Viper uh nothing on the compiler s

okay um let's see who do we have represented Basu nothing changed um evm one any changes in the past couple weeks worth discussing nope um do we have rest on the call it doesn't look like it uh do we have GE on the call doesn't look like it do we have another mind not recognizing any another mind changes any another my names and Aragon uh anything any Aragon two people on okay it's not surprising that much has changed all right so next to I have some

update on solidity so basically the functionality is merged and uh but now we are focused on on fixing uh fixing some minor issues and updating updating solidity tests to to fully uh be compatible with the with the eof format yeah I mean like we have like all the op codes needed to generate code and like we proceed like said we proceeding with like last changes to actually run semantic tests that kind of prove that existing code can work on top of UF and then we'll be proceeding to the next phase which is basically finishing like

remaining stuff and making it more stable we're close to finishing the first phase all right is that an accurate representation yeah okay all right um anyone that I forgot to mention before I move on friend you

still have your hand up yeah so I am working on an assembler uh for both Legacy and eof um so I have a couple of questions one is are there any assemblers that already emit eof code other than maybe like um Ule on maybe not on Main but on on the nightly or or whatever build works on that that will be my first question and I have another one anyone know the answer to that I'm not aware of any okay so

that just don't say that don't know of either but like we have assembly Imports in solidity but just wanted to confirm yeah does not support e yet oh okay so there are currently no um assemblers or compilers that emit eof no we need to lock the St the spec down that's I think the big barrier yeah okay um okay so that's good to hear could be a little valuable um and around this I as I design it I have a couple you know questions come up maybe there is one that I want to focus on right now the exchange up code which this is about

like the text based representation of up codes right and maybe the exchange up code is the most interesting one because conceptually it takes two values which are two stack depths but the way that this is represented in the bite code is by the sort of like um a base and an offset right the n and M are essentially represented as n and M minus n um so when we make a text textual representation for this hop code would you sort of show it in the same way as n and M minus n or what I think would be

better more readable is to just write it as n m in the text and then the assembler would actually do the encoding to the what the bik actually expects so has anyone thought about this um and would you agree with my thinking here um I think it would make sense for it to match the the semantics more closely so the Raw One n comma M minus n okay someone on the chat is saying the other one so we currently have one on one two one maybe I personally I also think NM

would be clearer um but although it's just really a matter of defining the convention and then we will just all adapt but like I think if it's close to the bite code it's easier to debug like if you're reading it um do the calculation your head or something but if it's like doing some conversion then you have to understand how the assembler is doing the conversion but how is doing the conversion much different from like a label jump and letting the assembler do the math for how big the absolute jump is yeah and another similar thing is our

jump V which in EN coding it has a number of jump table items so I would there forp I would also like list only the offsets not list in the first uh size of the table Yeah so maybe it might make sense for me to propose a written textual representation that we can all agree on so that whenever this is used by tooling um stuff like exchange and arj B are all represented consistently personally I'm I'm I would prefer n m um cu the I feel like the the role of a text based assembly is to make things a

little clearer um technically in the Vite code it's it's not even represented as n or M minus n because it's like n minus one and mnus N minus n minus one so n and M minus n would already be a little bit of a difference from the bite code itself I don't think we would be I think it it would be good to go a little further and do that so anyway I'll put together a a proposal uh next couple weeks um and may we can center around that from s say I just wanted to add that we'll have basically the same problem because we have to Output

assembly and we haven't discussed that it but personally probably also suest going with clear presentation because like that's basically just internal encoding that it's not like the clear number so yeah but just saying that we have no decision that yet so kind of also kind of unsure what we'll end up we I probably recommend that the one we were suggesting cool thank you for the input okay anything else on client and compilers usually that's the shortest section all right next on the agenda we have

uh here's my agenda uh EIP 7834 any 7834 here we go um yeah so I just pushed the fix to fix the linting and so on it's been passing all well also the E magicians link yeah so far we got positive feedback um but not much feedback to be honest yeah I would love to hear if anyone has anything to say

about this so one open question on this that I think we need to um get right for this and set as the standard for future um is the header ordering and the body section ordering um and I don't know what the right answer is but as you mentioned in some of the rationale we need to keep uh the metadata number to five so we're not changing any of the meaning of the previous sections where um Cod of two types are one wait not yeah types are one codes two containers three metadata um data is four so metadata would be five do we sort the header absolutely by number or do we

sort it by container order because the container order we have to have data section last um because of various reasons related to um the pending data and making it easy and there's a proposal to make kind data o FF and that's the other option is to make it FF so those are I think the the that's one class of open issues and of course the other class of open issues is is this the appropriate thing to add to e eof I'm in favor of it but I'm not sure everyone is I'm not sure that's an absolute 100% so those I think the two big issues um anyone else have comments on

this does anyone know that EIP to make kind data FF you have not seen any [Music] uh do you want to make this a new AP or just up the uh existing K I thought existing K appropriate for adding the metadata or

for um no for the FF the question was about right yeah FF do we wanted to yeah change that in 3540 that would be my bet but I'd like to hear here yeah definitely not a separate for this it's okay to because it's yeah yeah it also it it has its own Merit and one risky thing is that they already have um RS already started doing alphan Nets so there might be code that has the

04 um that is the risk but I mean I would see this change also to fall into the category of changes that are done after the first deit right okay yeah we're not locked in yet it it is it's not the same level as if we actually shipped it onto Osaka and then changed it oh yeah um if we think this makes sense we can also I mean yeah incorporate it in

current EIP or just the larger IP like to make data ZX FF to the metadata EIP or uh I don't think this this is I mean changing the section index to FF has its own Merit so it doesn't have to be attached to the metadata section EAP okay and then I mean if that if that ships well um I mean the the metadata section e would need to be updated right because we already

considering other incompatible changes like changing the order of eof create so having incompatible Osaka zero and Osaka 1 bite code is um something that's going to be happening anyway yeah I mean we could have I mean no section index for that's also an option but I think it's it's kind of secondary okay apart from the ordering is there

any other concerns about the uh this the uh metadata section um I brought up some uh concerns in the Discord uh just that um just kind of makes the container format more complicated when it could be for example Viper doesn't um have a metadata section in the runtime uh which um part of that is for the reasons that are actually explaining the rationale here so like it's unreachable by the runtime code for for sure because it's not there and it also saves some space um I get the appeal of

having some kind of section of the code that's unreachable and unreadable um but I just think it could also be addressed in other ways such as having stuff in the init code or I guess um in the current way to deploy UF contracts is through Legacy contracts so it would be like in the Legacy contract actually and then um you deal with it through tracing or you know via emiting events uh that's another thing in the evm which is like unreachable and unreadable by contract code so what this um init code data would be at the end of the data section is how you would handle it if we didn't

have this uh how would Viper do it if we didn't have the CP it's in the NIT code so it's not even in the container well the init code is a container the init code is a container for eof it has to be a container we could it like comes from offchain right okay so well yeah it would be onchain um you could have offchain in it code but there's then You' have to have your offchain um tooling to get the data and it wouldn't come back onchain the init code um shows up in the

transaction the init code container shows up in the transaction so it would still be on chain if we had it um as part of the create transaction but it would still need to be part of the container or it could be appended as extra data not use it part of the call I guess yeah so that's what I'm saying is that another option is for it to um be an event or um how would that make sourcify would that would that make is only having it theit code would that make sourcify job easier harder definitely definitely what sorry definitely harder because getting the init code

is like couple more steps difficult than getting the run time runtime is quite straightforward uh init code you need to get the you need to First have the transaction hash if you don't have the transaction hash you have to do a binary search over blocks then run through the transactions to see which transaction contract and even after that if the contract is a fact is created by a factory then you still need a trace you need an archive node to get the transaction traces to be able to get the init code so in general I find runtime bite code um to be more proper for this kind of information but I guess um any

kind of tool in is is is can decide on put it in init code container or deployed container yeah so that's another thing I was saying is like um you can make off so it is a trade-off between in Viper we've made the trade-off between like runtime bite code cost and um you know tooling difficulty but like another way of addressing it like I mentioned is to have an event for creations and then you don't need to search which I don't know the compiler inserts or something uh but yeah I guess I'm saying that it can be addressed with like conventions and application code rather

than adding a a new kind to the to the E format so if we even if we don't add it um that doesn't preclude compilers from adding their data to the data section still keeping it I mean it doesn't preclude them from from the practice that the Viper doesn't want to do yes right like I said I I think there is an appeal to having this unreadable section in the runtime code um but I'm wondering if there's like other ways to address

it because there are other Solutions within the evm that can be us um at least from source code verification side I find having a separate section particularly appealing because then it's quite straightforward decode and where to look for for metadata and for the data that we need to ignore because once you start um mixing metadata with data or code then the verification gets quite complicated then you don't know where to ignore when you're verifying and

again as mentioned in the E AIP if that part affects the rest of the data or code then it gets um impossible to do the verification oh even even there's a convention that convention needs to be really well defined in if we want straightforward verification yeah but like the metadata is already done by convention and um now that I think about it I think the event solves some other problems with um Factory contracts like you don't need an indexer in order to find uh who deployed

what and so on okay um I think some of these should be addressed then in the uh rationale and security considerations of the EIP um would any of these be blocking so where we wouldn't want to do this or these just uh improvements for iteration on on the better way to use it okay so I don't hear these as blocking I think we just need to address these concerns then in the text to the EIP sounds

good okay next on the agenda um is generic factories and deterministic deployments I think frano posted this so I just wanted to sync a little on on this um and I think it it might be related to the counterfactual deployments that Dano you have been asking about so on ethereum um there is apparently a use um and like developers have become accustomed to and like and

sort of demand deploying contracts on the same address on multiple Networks and especially now we have many chains right I'm not I'm not convinced that this is actually valuable personally but a lot of people do believe that and use this um so many protocols like I don't know unisoft is is running a competition even now to get like the coolest address that they'll use in all networks for V4 um there is no real mechanism to do this on on on these chains um so what people use is what

what's known as NYX trick or deployment method where you kind of mine a signature for a transaction um by trying random numbers I don't remember exactly the structure of the procedure um and in this way you you can get a transaction with like signed by an account that you don't have the private key for and you can send this transaction to all chains and theoretically and deploy it so this relies on the old type of transaction where it's not bound to the chain ID and also it it relies on some assumptions about like

fees because in the time in the transaction for which you will mine a signature you need to include the fee parameters and so I haven't looked exactly at how they do it but I assume you just set a very high gas price and assume that it's going to work um so this is like many considerations things you have to do to get this to work so what people have done is to use this method to deploy factories and then you use those factories to deploy without having to do all that thing so there are many of these factories you may have seen the one that comes to mind uh now is um create X if you go here you

can see sort of some of the motivation and all of the work that has gone into it and all of the sort of requirements and many functions they've added to the interface for those requirements so my uh point that I'm I want to raise is this kind of factory contract is which is generic as you can see it receives it's like the function deploy create it receives the array of bites that it'll just pass on to create so this kind of factory contract is not implementable in eof and so this sort of implies that

there will be no method well I mean other than mining these signatures to to deploy contracts at addresses um and well again so yeah it seems I I don't know what you guys how you guys feel about this um if you've thought about it and also if you are considering I haven't looked at TX create I don't understand for when you think that will be scheduled um I understand it won't be in the next Fork but I think this is something we should

consider yeah I'm here as a uh application developer who depends on that behavior um and and not only that behavior but also um uh the ability to create contracts in an unsalted fashion uh because if you have both salted and unsalted creation then you can uh deploy contracts in such a way that they don't depend on their bite code but then do depend in a non-sequential way on some external data um and then so that pattern gives you a way to both securely and flexibly deploy contracts to uh predictable addresses on different chains or the same address on

different chains uh in a in a permission can you describe again what you mean by unsalted uh so the saled creation is the create two style and then unsalted is the older create style where it depends on the nons and you have a use for both yeah and when you do this do you use the the this kind of generic Factory or do you use uh the signature mining method yourself um we would love to use the signature mining thing we found it to be a little bit brittle uh on some chains

that have uh what I would call unreasonable gas rules um the problem is that if you don't use the the signature mining method then you end up having to depend on somebody else's infrastructure to you know tow hold your uh your stack which is also problem that we've encountered so um yeah I mean there's there's no perfect solution I me if if there were a eof enshrine perfect solution we would adopt it immediately so I should mention there is an alternative to this kind of so the create x uh Factory was deployed using NYX method so this kind of signature mining method there is an alternative which I think is the one that nosis uses

um which is the have a private key and they sort of they take care of deploying on each Network when needed and in this way they're not bound by the gas thing but the availability of the factory on new chains becomes uh reliant on uh safe doing this for it uh Charles asks what the exact reason createx is not implementable in eof so in eof the you can only create contract using eof Create that you have um declared in your container right or is there a workaround

for that uh yeah I see what you're saying so basically in EF you would need to like separately deploy the factory contract and then ask create X to like uh run it for you right you could delegate call in if we do the eof create then you'd have to have on on Chain by a second transaction before it could actually deploy it yeah so this is the other reason why I wanted to bring this up because it affects the design of eoff creates address formula so if we want this to be if we want create X to be doable in eof using delegate call

then we need to see what is the address formula that enables that okay yeah so probably a quick sidebar into what TX create does um a lot of description here but it allows you through an OP code to reference a contract that is in a transaction um so this preserves the code interp and aspect and that you don't need to know the contract but you would go you would give your TX create and you would have either an index or a hash um you'd have a hash into your into your transaction that hash would be in the transaction we need a new

transaction body type um to where it could carry uh these various where is the specfication for the transaction type um so where it could carry these various um is it data ufu trig grades but you would put the you would put the contract in your transaction you would call the factory and it would reference the contract in the transaction and then use its local Valu to create the the hash deterministically um I think you have feature upgrades so I think this is yeah probably the the best description of what's going

on um for what we have plann for TX create it was cut from um Petra for complexity concerns um and depending upon when Osaka ships I could see it returning if Osaka ships in slps in at 26 I'm probably going to pitch it be added for the first revision but if we're actually going to be disciplined and ship it before Dev connects um then I don't know that we have room to put it in so there are there's a couple of issues going on there so it might need to wait wait until Amsterdam to really get this fully working um in parody with uh the existing thing and I and I agree with agree with Duncan that we need to have this this use case fixed for eof where

people can bring in arbitrary contracts into fixed known addresses if they have the right to hold okay so TX create enables Factory contract generic Factory contracts that's the goal um and I think there's a way with delegate calls we could write one that we could do it without CX create but we require two-step deployment um yes I need to think about but it it enables Factory contracts this doesn't by itself solve deterministic deployments because you're relying on a factory that has the same address on multiple networks but I still need to get via next method or uh eoa you would

still need to get it to hold yeah so I think it's not the job of eof to solve that but I do think ethereum should have some reliable way to to do that without the signature mining trick um but that would be out of scope for this work group um and then uh before before we move on to the next thing there's also the question of um right unsalted Factory deployment because uh without an EA uh deploying a contract there's no way to get a non derived contract address both both TX create and E create are salted rather than non

derived um can't you just solve that in the in the factory contract it maintains the nons manually uh both both of these op codes uh create addresses the same way that create two does and so ultimately the address of the deployed contract depends on its init code so if you want a contract that does not depend on the init code the the the address does not depend on the hash of the init code um you are stuck either um doing something crazy with you know EAS and like slashing or you know some kind of game uh or uh you know giving up because even Nick's method

um creates addresses derived from init code yeah so I've mentioned this on the on the you the relevant issue I forget the exact number but um I'm pretty in favor of removing the witness entirely and I think that just solves all of these problems like the problem there's the problem with um createx uh if you didn't have the witness then there's no issue there I think um uh correct me if I'm wrong um it also solves the nosis safe issue where you like it's really hard to get the same address on different chains and it also solves this issue because then the the hash for the deployed

address is just based on the salt which is whatever the the factory chooses so the witness is the hash of the code that we're putting in uh yeah there's been several witnesses that have been proposed one is the init code which I think has been kind of uh rejected because in euf you can't really you're not supposed to be able to interp code um and then the other ones are like the the code address so like the delegate called address and the uh innate code um contain uh section index or container index yeah that makes um like a

counterfactual addresses more difficult does it make them impossible no it makes them no it's not impossible um but you have to I I spoke about this with p and basically you have to trust the contract deploys the um that calls EF create so basically there's two cases if you're an EA and you want to ensure that something is deployed at a that specific code is deployed at a a specific address then um you basically rely on a factory that

will respect the hash that you give it of the code or something and then the other case is onchain uh sorry if that's not clear but like maybe I haven't had enough coffee but um basically the other cases if you're on chain then you can't introspect code anyways so like you can't do the counterfactual deployment and with create two um there's a very important property which is that you can compute the counterfactual address in your code in the like on chain uh but because youf create removes introspection it's

there there's no possible way to do that if there's a witness in the in the deploy in the hash computation so so what if TX create you created a factory where the TX create used the TX hash for TX create and required that to be the salt would that solve the counterfactual problem because your salt would be fixed to your address so you could only deploy it with one address so you could then only deploy one possible code to that address is that the core of the counterfactual issue um that that fixes the counterfactual issue but then it you know opens up the the unsalted issue again I I think right the the clever solution is the factory

gets to specify the salt or the witness as whatever they want and then if you actually want counterfactual you have to make sure that your the factory doing the deployment is um inserting the witness as the hash of the init hash or as the hash of the init code so are counterfactual and unsalted compatible um think they are no I think I think if if you if you do the thing that I just suggested I think you can get both it's it's just not the way it works right now and it's a little bit tricky okay it's kind of a break from create

two semantics but I think um it pushes more responsibility to the user to like not have a collision but uh it preserves the important property which is that somebody else can't like force you to have a collision um which is I think more important okay um I think we need to time box this because we still need to talk about testing I don't think we get to a res resolution switch St anyway um but yeah these are all great things to think about as we talk about um the hashing for eof create and I'm probably also going to skip over

since it's related the um where's my agenda skip over e create hashing um would it be okay if we skipped over the code size thep or do we want to discuss that for like five minutes or can we push that off to January um I can just give my feedback real quick which is that I think it should be accompanied as I said in the comment uh the code size limit change should I believe it needs to be accompanied by the relevant um format and op code changes otherwise you have like inaccessible code or you have to like do this weird thing where you

change jumps together um yeah okay we'll discuss that more in depth in January but let's talk about testing Mario do you have anything for testing not particularly um we are been working on devet 5 so so far I see that there are some outstanding PRS uh for EF I need to get back to those probably um

if you give me this week I I can I can try to finish them up um otherwise if there's anything urgent to for me to review just let me know and I I can I can try to to prioritize yeah but yeah not apart from that not not not that much yeah okay um cool that's that's easy for testing so a couple of things that I also want to talk about for testing um have to do with fuzzing um so the first thing is I want to discuss is the um is some of the proposed changes I have to the trace specification I have a new version set up I need to fix this sample here but the big changes here I

think that um this goes out to all of the clients um is the PC equals zero handling for I think my notes here are going to be better um so the first big change is we need to have an agreement on what PC we're going to use for all of our Trace semantics and based on fuzzing we either need to include the section number into the trace or we need to set the PC equal Z to be the zero of the container itself um because we need to be able toid and if we have the PC equals Zer and have it be the absolute index within the container then we don't have to um enumerate which section we're executing as part of the trace I it'll be clear

just from the container itself um so that's my my one proposal and I have Basu has that my GE Fork has that and then changes I put into NE mine has that right now ref do does PC equals zero for each code section and evm one does PC equals Zer for um the first bite of section zero um so that's what I'm going with there so like feedback on that either in the um the the uh eth magician discussion thre about it um or yeah feedback on that but my experience with that because what where this is coming from is I've

I've ridden a fuzzer um that is not much so far it only does about four things it increases it it adds a push and a pop instruction and it changes uh push contents right now um but from this I've been able to actually find three implementation bugs in three different clients so far Basu had one GE had one nethermind had one and I haven't been testing eof um evm one and eof ref yet because I don't have um a trace statement that actually works for them um I suppose I could turn off the tra and just try off the end hash and see what we get there but getting getting uh fuzzing is going to be essential to getting the comfort

from the other core devs that what we've written is stable enough and won't cause consensus issues while there may be no spec issues we want to also get rid of implementation issues and fuzzing is the best tool we found in addition to reference testing to to get these fixed um another interesting point that I probably want to make here is the Corpus I'm using for the fuzzer right now I don't generate a corpus from zero um I'm using the Corpus from the reference tests I run the reference tests in a mode where there is a single test profile um it takes forever to generate this uh but it creates a very valuable basis to do a lot of these changes because a lot of these bugs that we're finding are just one off from a test um so that's uh quick overview of what I'm doing with

funding any comments questions from clients from developers so it's another thing I want to point out is one of the changes I'm doing I'm also in the spec doing quality of life changes um this is the old 7756 darn it so I do have uh some changes in the tracing darn it

so here we can see I also changed the op to become a hex number and the gas numb to become numbers and I also included flexibility that people reading this should expect numbers could possibly be hex encoded numbers um so this I think increases the readability so when we get to some of these op codes We Know by like F9 it's XT delegate call it's a lot easier to read than like 250 or whatever 248 whatever that that corresponds to because there's a lot of magic that goes in corresponding like 61 we know a push one from reading these and then we get to gas and seeing that the gas differences it's a lot easier to do the math when there's a problem and seeing that the difference is 2500 rather than having whip out your hex calculator due to conversions into a

delete so those are some other changes that I have for for quality of life for end users but I've also indicated in there that clients's reading these need to accept both I have go evm lab patch out there that handles that for op and all the gas already and I think the uh go evm lab already um handled some of okay um we have six more minutes in the call um any other discussions we want to have gra upside time box the hash discussion early but thought we'd have more back and forth on testing can anyone still hear me

y yes no feedback good me I wanted to ask about the um generated F tests is is it is there a sample that we can see um or that you can share sure the if was um let me show you I think 31's got one that's got a failure so here is like a typical so go ofm you run it in batches um you create a set of a corpus and I delete the stuff that's not kept um that one had a good

pass um 39 had a failure there we go so when go has a failure it spits out the test case it fails it and from this in the tool I can parse the output and save the file and if we follow the same if we turn tracing on it'll tell tell us exactly where the difference was was handled in this case there is a pricing issue with nether mind um they're charging 950 more gas for some reason I don't understand yet and we see that the EXT delegate call was Operation before and after now this can be somewhat um uh uh deceptive uh because we don't have the memory in here um one of the bugs that I fixed in um and Basu the problem was that it wasn't doing the

memory expansion correctly um for previous calls so a further call down the road would have the incorrect gas call amount because memory expansion wasn't done there are some cases where like in a failed call you still do memory expansion um so this is generally helpful but really what happens is you go back and you look at the entire Trace that it creates and this it normalizes the trace into something that it can just run a diff against so here Basu and gu would just be ABS absolutely the same and it's when you get to the another mind um that this value would be different you run the under plain old text diff and this is where you would see things are different and it's still using the old op numbers I'll probably upate that to use hex here pretty soon um but you can see the state routs

2352 um and this is 41 da uh I sorted accidentally here we go 41 da 41 da so these so basically get the greed on it and nether mind with the odd person out and so the tests that are generating they're just date tests and what I do is I go and I find all of the ef1 eof codes and I do my mutations on each and every one of those I do one mutation and I keep a log of the mutation things I do they're not exact but you set a push to a random and block zero um and a bunch of you know add a push pop random there's probably a magic value push magic value um set address address I got some good stuff there um

but another thing worth pointing out in the way that I handle this is when I parse the eof I do more than just parse out sections I parse out basic blocks which is a a compiler optimization step um where you take all codes that do not branch and he puts them together in a basic block and then he puts some notation say this basic block flows onto this one or it branches to this one based on whether it's a jump or not and So within those basic blocks I'm able to add and remove um code no problem that's why I did the push zero pop is I changing the size of these basic blocks and I could go back and I could reconcile the absolute position of the relative jumps and I think that's one of the problems with just having a uh a plan old updater that just manipulates

and changes the bytes or inserts random bytes you're not going to get the same frequency of valid eof code and that's another complication that's presented in into the fuzzing here is all the code that's fuzzed has to be valid e code so once I do that manipulation on the blocks I do a reconcile step where we repoint with the uh the relative jumps we also make sure that the jump Heights are correct as well and if the jump P are incorrect and we throw it out and I still right now I don't have it perfect so I bring in the eel code and I do a validation of the code and if the code doesn't validate I pitch it off um so there's no mutation if it doesn't come back as valid um but this is you know it's eof presents some some

complications to traditional fuzing and we just apply um stuff that's worked before it's important to not that um this is not a new approach uh Google did something similar to test ebpf they created a a validation aware fuzzer that would only do valid fuzzing things and from that they were able to find ebf bug that was on Hacker News a few months ago so this is not um it's not a novel technique it's been done before and it's it's shown to be successful so cool are you happy with the approach so far or with generating for example will input for an assembler and then

which is easier easier to ensure valid and then assembling that into bite code would something like that be helpful uh we could do it in assembler too we would need to write the assembler and integrate it in I'm manipulating the the bite code directly and then reconciling it um the reconcile of Stu also I forgot we need to track the stack high in the inputs and the outputs as well so the reconcile also helps calculate and that's some stuff the assembly would help out with too so yeah fuzzing directly into assembly input would be another possibility of how we could write the fuzzer step I'm happy with it right now but I haven't written the more complex ones on my Hit List um which is stuff like add a new code section um create new code blocks I'm assemble code I already got that uh add

arbitrary operations which is something I need to do remove operations add Branch collapse section and uh move a section out to another move a section of the block out to another function these are you know kind of inspired by an old Scientific American article where they're creating computer viruses and memory and creating an ecosystem some of the stuff is way back in the 80s but I've always you know that some of those techniques there were just generally useful in building some of these things so some of the mutations and the goal is to finally get up to parody with fuzzy evm fuzzy VM areas's project where we could do all the mutations they do just do it in eof um but do it in Python make it part of the e framework um is the

goal um we're overtime so I will go ahead and let people go um our next call will be in a month um again if you have any comments feel free to comment on the Discord feel free to comment on the eth magician threads for these uh eips and I like to thank everyone for the time they spent and working on E