EOF Implementers Call #65

Transcript

I'd like to welcome everyone to the 64th eof owners call on the 22nd of January um I have the agenda on the um eth magicians um copied off of the agenda that was in the call I don't think there's been any late ads in the past five minutes yeah I think we're all up there um so the first item of business is the testing update Mario you want to kick us off yes sure uh so I just merched the two PRS that were like um hanging from like a couple of weeks ago and uh all seems good um for the deet 6 updates I think we should wait for um for everything to settle

before uh refilling the EF tests on top of that but I think we are pretty close to to finishing up up uh the requirements for de de6 so yeah after that I think we should just refill UF and just uh yeah make another release of have on top of that but yeah apart from that I don't think there's anything else from my side okay yeah kind of had a similar oh sorry there's one detail about the release uh which is the E W uh which we all love and uh so it's relying on ezm1 uh working to uh transform the blockchain tests from Legacy to eof and

I think uh that might not work until e um until evm one is on pectra devet 5 so um I guess the simple solution is to just turn it off which is I think one line in the CI setup so there not included in that particular release until we get our stuff sort yeah do you guys see um like E1 is going to take much longer after d devet 6 is finalized or maybe we can just wait for you and want to be ready oh six on top of we need to get to five I guess yeah I mean we we're making progress and um but I'm not sure how

much time do we need I'm I'm fine the only missing feature is uh 7702 um so I think I plan to start reviewing this probably next days uh I I'm not sure what in definite 6 is actually but I imagine it's it's not a big change yeah it's only the 7702 yeah it's 7702 the change for the U external contracts oh that's simple enough I think the reason they did the devet 6 is they didn't want to go straight to Shadow testing without a visible success yeah yeah exactly so the plan

right now is we cannot make the release for de 5 uh with the 7702 changes because it would break declines on devet 5 right now so the plan even if we don't have DEET 6 we are going to label them differently so we're going to have like deth 5 with everything that doesn't break uh on the current uh de 5 releases and we're going to make a release uh either de5 or a or a proper stable release with the 7702 changes um so yeah we what I what I was meaning is that we we we can wait until we have those D six uh changes finalized and then we can make make the release for EF uh so whatever the case is we uh the EF

release I think should contain the 7702 U changes in my opinion so we could think of devet 6 is Dev net 5.1 except we only do one number so it's six yeah basically yep all right anything testing Rel anything East related if if anyone is missing a review please just ping me um there's a lot of

PRS open right now that I'm trying to get merched for uh D6 but yeah if I something slipped through the the cracks please just just ping me I'll try to review yeah I'm I'm slowly but hopefully in like finite amount of time I'm trying to move all the remaining validation test from or repository to to East so that's where the the prequest come from on on my side um think it looks manageable in the way I'm doing this so um just wanted to mention that okay um for fuzzing there's no new

published findings and publish is important I don't consider it a trophy until there is an East test written um there's one thing I'm working on with GTH um that I think will become a trophy and there'll be a test out there relating to eof create um that'll be coming next week or in two weeks um and another thing another problem we're getting into with fuzz is that fuzzing provides useless signal if the clients are not on the same Petra devet level so it really limits the number of clients I can pair up um if there's one difference um if one has know Petra four five or six or if there's even a bug in five or six if the fuzzing tends to find it if it can manifest in the evm which I guess is evidence the fuzzing is working but it

makes it hard um one thing I did do over Christmas is I had all of everyone's um I had local builds of every evm that had eof up to devet 4 level and I was able to run the fuzzer for about a week solid with no findings with the tests that I had um now the tests aren't complete this new finding was off of um something relating to eof3 and um the data loob operations so I didn't have that test running last week so there might be some other bugs out there but we're we're pretty good right now um so any other testing updates before we

move on to client updates all right so let's move on to client compiler updates um actually just to um follow up on the testing so ideally you'd want everybody to be on the latest devnet with eof is that correct yes that's going to be the standard for Osaka zero um but until everyone gets their their regular clients up to six um there's not much value in pushing eof on top of it which is why I'm not pushing it in this meeting because getting everyone to six is more important for

getting pectra out the door and getting Petra out the door is going to get us progressing on eof faster Petra has to ship before we can ship eof so that's why I'm not pushing too hard okay y just to just to clarify a little bit so de 6 is not confirmed it's just the term that I'm using for this breaking change that is going to be end up in in PR um but any regardless of what of whether D six happens or not uh we should uh like Target for UF to be on top of that change that breaking change yeah yep one one more question for the fing

uh do you use state test for it and do you require those new fields that we talked about in Json format so um probably I use the state tests that are generated by East um as the seed for the for the generators um I run it through there's a couple of flags I can throw on to um the test Generation Um that will print out one test Prof file um that takes a few hours just because of how fast python is um the way it's set up which isn't a problem I just you know set it to run overnight and then come back and I have a 2,000 uh seed files that I can generate off of um there may or may not be new fields in

there that need to be interpreted I know that did break Basu um I could I had regenerate and resin Basu so I think the new field are going to slowly start coming in but if you're running if your if your um state test Runner runs against the current um uh pectra Dev Nets you should be fine okay cool and additionally the state output basically the Json that was outputed uh should we add new fields and require that for the fuzing to happen yes let me write this down okay I need I need to add those and yeah okay so DEET six or whatever we call it add new fields to the Json

output Tracer and maybe add new fields to the state test Json if needed yeah let me find um EIP 7756 and this is probably a good time to have that discussion um of all the fields the most important one second sy6 so of all the fields the most

important change here that people are need to do for their um for what they've done for the eof tracing is the way we're handling PC um I've gone back and forth with this with several implementations um and I think what needs to be done is the PC needs to be zeroed against the beginning of the container so your first line your first execution won't be pc0 in eof it'll be like 19 20 21 22 depending upon how big your header is so section Z by0 is going to be at a higher number um and my rationale for this is either we would need to require that everyone then put um the section number in there and uh to fuzz you probably need function depth

too this is needed I think function depth is something that I'm going to require for need to require for fuzzing U because of the way get handles its duplicates um but we need to require people to have section and function depth so function depth I think is going to become a required one that should just be an easy thing to put into it but from that with PC um what go evm lab strips out is a need the PC the op code number um the gas remaining uh and the depth and those are the required fields that it does it's fuzzing off of when it's op code level there's another mode um where it doesn't do the per line tracing where it just checks the end um State at the end where it checks the state hatch at the end uh

it's faster we that's the stuff that I ran over Christmas um didn't do the line by line because not everyone had it in a way that wouldn't grade diffs um but but one of the things that I've seen um that uh the fuzzing might miss is it might detect a change but it won't commit it to anything that would change the state so we would have a fuzzing difference would slip through because we're not doing line by line fuzzing checking so I think that's the big issue there why we want to get line by line checking is because it's higher quality is going to find bugs quicker rather than finding the bug and accidentally get that bug into some way that is persistent um the way we have state tests written um there's a high likelihood it's going to be persistent because we always

record all the data and check the data at the end but when it's a purely generated piece of code um there's no guarantee on that so so as far as the the recommendation ones if we can get PC to zero off the container start um and make sure everyone has function depth in there um and that's the even though I have listed as optional here I'm probably going to move it up to um required if present based on that let me update that wish I had tabs here

all right really last call testing fuzzing any more questions all right client compiler updates anyone want to go first volunteer uh no change since last call for another mind um same Basu no change vm1 no change think same with thre go no changes okay um solidity

anything uh basically not much change from last time like we working on prepping it up and releasing but in terms of like functionality we merged the like all we needed and we're mostly working on like having it tested and we also like kind of trying to decide of the next on the next mil like which because like we're going to do some part of next features in q1 and like the question is like which specific one like whether we would like to have like optimizations ready uh or like properly support like or outputs or assembly import and stuff like that

all right um Viper do we have viper on call Charles yeah similar um not much change um although I was wondering if there's going to be eof support in pvm or if anybody um is interested in shipping that I don't is Pym different from eels yes yeah I guess we need to talk to the snake Charmers on that are they the ones that own PBM yep

yes um I think they also um so we have multiple backends in our test harness PBM is one of them um and I suppose they're probably a little nervous about implementing it right so eels does have a fork that supports it it's not branched off of the current um eels so there are some changes with some of the types um that cause problems um if you're mixing current and old uh eels code that's something I'm running into with um East um but yeah it it appears to generate the test cases um correctly right now

so okay so yeah we'll need to Ping the Snake Charmer and a their fears they might I mean there's enough all the landmines are known so it shouldn't be too hard for them to come and ask for help if things get stuck have a meeting with them um next couple of days I'm I can try to ask them and and report back all right cool um any other client or compiler updates before we go on to spec and other issues all

right the three items we got listed today are UF metadata cross chain addresses and Osaka 1 spec changes anything we need to add on this list before we start going through it cool so let's start with eof metadata um we had uh yeah so I did a quick Spike trying to implement this in one and in have some test in East so far so good uh it's very preliminary but it seems to work and U there isn't really much to say maybe but it is it is slightly tricky because uh

well with two optional kinds of sections uh it does um uh it is a bit Ian more complicated than it used to be and it also the metadata section is like a new it's pretty specific it is not like any other section because it's not like the type section because it's optional it's not like the code section because there's only one and it is not like the data section because it if it if it's not there then it is not mentioned in the header so it's like you know it needs

New Paths to to handle this like this thing but I I'm not sure if we can improve the design so it's not problematic because obviously we want it to be optional and um yeah uh and then so I've so far written only validation East tests and then I I'm thinking for the execution tests it would be nice to be just parameterize all or many existing tests with hey add a metadata section to this

container and then just run the same test because for the majority of cases well the execution is the same it might only differ in gas cost of the deployment and I think that's it sounds good I think I mean we ideally we should select like a subset instead of just uh refilling every single test be huge otherwise yes yeah so H we can go either way with a marker for example we can create a marker for that or um let me think if I can think of anything else but I think marker should be should be the way to go yeah I mean

if this doesn't um make you scared then I I think it's it's good uh no it sounds it sounds good yeah no no no it's it's it sounds fine um but but yeah I would I would suggest maybe just a subset of the of the tests um just relevant tests and then just going with a marker just to make it easier yeah I can help you with that if you if you want I I think it's it's way too early to to do this um um I wouldn't bring it into East I wouldn't bring it in East until we have blessing from ACDC I mean AC of course of course I mean we cannot because we would need to come up with a fork that

it lives in yeah until that Talk's not going to happen for about a month we're not going to discuss Osaka beings for a month yeah yeah yeah totally yeah I understand this was just like you know trying to um To Tread the Minefield and see if there's any mines left there but it seems not I mean one thing that is kind of troubling that if we keep eating if we keep adding optional sections to the header this is going to be a bit maybe unwieldy for example I was thinking I mean we cannot we cannot say that we should not have a metadata section on a container on on a container that has a container section because

obviously we want to have a metadata section on a factory for example right MH uh but for example if we could rule out a metadata section uh hold on uh oh no that doesn't work I had something in mind but I think it doesn't work so I mean the less optional sections we have it's going to be better I guess yeah the gist of it but my my my concern on that subject is that um the future of expansion might be more optional sections or we need to do a major version number that would impact parsing um so that's that's something to

think about is the cost of new sections as a means of expansion yeah I'm just just leaving it here and I I think I'm done okay uh quick question I wrote in the chat what about not making it optional and whenever it's not used you just say that the size is zero yeah so that that would be nice it would cost us three bytes for the zero size and it would also I mean the problem maybe this not a problem maybe we should consider it would be that having I mean it would um definitely uh

right now the EIP is like an addon and or I mean all containers that we have and produce and test and what not are valid with the addon and that would not be the case anymore if we required the metadata section that's it maybe I'm over over reacting on this well if we know now that's which sections we need to leave at zero we could we could code them in but yeah I mean we don't know what's going to show up in the future so those the new ones we add will have to be optional I I mean this is like you know maybe if we are sure that it's going into Osaka then we can make it

obligatory it's more like this and then um that would be a break change for for for e but it would maybe it would be better yes okay any other comments on metadata section um maybe one question why do we why do we need metadata could we just could like s wiper just use

data so this is your question yeah this is a request from the sourcify team um the problems with putting it at the end is then it's a it's hard to detect where the metadata exists when you pend auxiliary data to it this is the problem they have today um when deploying contracts um when you apply um class level data at the end that you would read via code copy so putting it in a section is isolates it so most places will parse it and discard it um so it won't and it also is data that cannot be loaded by the evm yet is still associated with the container so which this is kind of useful there in

that sense okay makes sense that's a good argument I mean um I've discussed this before and there's other read only sections in the evm so it could like just be a log but uh this is all in the discussion thread on mags yeah yeah because other options are just to admit event while you do the contract um it's just a question of how people want to read it from the um From the Block to explorers yeah it seems nice to bite code argument sorry go ahead Peter there was a there was an argument I cannot really site right now from the sourcify team that it's it's really much better to have it just appended to the to the bite code that's you know being verified

in this case um I think the argument was just that emitting a log or doing it in the init code is less or there's no standard for it yet so they can't rely on it um but if everybody meaning the compilers I guess agreed to do it um then it might be okay I think oh I think it was it was about um not because if you I guess emit a log then you need more infrastructure to read this log because you need to index um yeah especially with 444s people are and this this this yes this amplifies this right and especially with

stat list you might not have access to the creation of it yeah yeah yeah yeah yeah I know I remember right right okay cool all right let's move on to the eof TX create and cross chain addresses um first let's talk about EFX create look is this the has oh this is the document so uh like a very brief reintroduction there's a there's been a discussion about the hashing schemes for eof create

and then it sort of escalated to just thinking about the Hing schemes of eof uh deployments in general which is like how do we um obtain the address of the deployed contract and so we wrote up such a document that tries to list a few scenarios and also build these scenarios out of out of sort of building blocks which are different combinations of solutions and and we have asked for feedback and um the aim of this is to decide whether we want to change the current spec and also if and then how do

we change change this spec and uh yeah does anyone has has anyone anyone gone through this document and has any comments suggestions or feedback so scenario one B irregular State change um at the same time Dano has proposed an ERC which seems to do the same thing but it's not an irregular State change if I understand correctly

right right um that's kind of threading the needle there um one piece to put in here that's going to make um isc's uh viable I think is that um we're talking about replacing the identity pre-compile and in general replacing the pre- compiles with actual contracts so that opens the door to is part of a fork um adding a contract to a chain not necessarily changing the contract um changing a contract to to do something different to fix bugs is is I think the ISC that people would not want to see and that opens the door to some really um politically problematic issues but if we're just adding a contract um that has

precedent for being there I think that's going to um be an easier 1B is going to be an easier thing to push with an is with an irregular State change what do you mean by precedent for being there um so let's go to uh Osaka's change list um GitHub ethereum PM um actually let's go TOS requests and this is going to be how do I find the ones that are

are you what are you looking for um what's what's theic username vbin what you're looking for this one so he's proposing 7666 for Osaka and EIP 7666 is to eify the identity pre-compiled and what this specifies is taking this code and Publishing it to address four and this is from vac and so this I think is really going to change a lot of

people's minds on the idea of as part of a fork taking a contract and P pushing it out to a specific address where it doesn't exist before um whereas because of people's experience with the da there is a lot of knee-jerk reaction um I'm kind of in that camp um uh we're doing changes to the chain as part of a fork is is a nogo because of the problems it caused um this should be an eof contract that would be funny yeah um yeah I'll pitch that's a we should try that it's gonna be cheaper um yeah let me add that to the notes but yeah so that there's other people pushing this for for different similar

reasons um we can set the path to no ISC to be isc's that add contracts are acceptable and we still don't cross the barrier into isc's that change state or change contracts and those I think are where the real political drama Lie so I think this is slowly moving us there but I think for reasons that we have to go to and uh so what you're saying is that there could be a path to getting these Factory are there this one Factory or most factories as uh evm not pre-compiled I don't know what to call what to call them pre-

deepo yeah okay pre- deepo yeah that would be nice because I mean I was I was looking at other similar things and say like well the existing system contracts right like the beacon block routs um Etc they are deployed essentially using NYX method M find that correctly correct so what I was going to say is like I don't those are eips so I don't understand why the factories would be an ERC they're in that category um but if they can be just preep loys at the sort of hard-coded address that would be much nicer yeah so I haven't actually shipped

the ERC yet so it could become an EIP um I think that's one of the reasons why I haven't deployed it because because some of the designs still up in the air um Asic you have your hand up yeah just keep a note that um vitalic was never against like regular State changes in that sense uh in the sense of introducing new code not you know changing existing stuff uh if you look at the old like the original block hasp from him in EIP 210 several years ago that was the same same okay I don't think he was part of like the discussions when the actual block

stuff went in and well could have decided to do the the predeployment is there were some people who didn't want to predeployment [Music]

right um sorry what do you mean that I thought that the ear pre-draft ERC that Dano you put together that was a normal deployment right that is a normal deployment but to to totally shift to a different actually we are talking eof create TX create so if if this is a possibility if we could put those contracts on chain um as part of the transition we could potentially get rid of 7720 I think which is where we would um change the context of a create transaction to allow eof to be created so if we have those the ability to predeployment yeah that would be very good and it

would also having TX create as it turns out well it's optimal in many aspects like it does uh pave the way to um the terministic deployments I guess and uh and uh also it is uh um sorry stuck uh it's also a a compatible as the only I think option here MH which is it just it would allow smart contract wallets to just deploy arbitrary contracts period right yeah aa aa compatibility is

why I think we need TX create so it's it's good to know there's strong ARG ments for this because this would uh this would I guess close the discussion we have here if we can get T create in without friction then it's good yeah I think like if TX can get in that's fine um though I will say I I don't really understand the AA Point still um MH what do we mean by like that we want accounts to be able to deploy arbitrary contracts what kind of scenario what kind of use case that's still in the air I I I remember

um so I mean I think that's to make AA on the same level as a regular contract so with a regular contract you can deploy contracts with your own code um when we get rid of the ability to load stuff into memory and do a create um we lose the ability to do the create the current way the AA contracts do which is to load it in call data have your contract pull it off call data you know they'll call the deterministic deployer um so we need to have some way um that we can reference a contract that is not known to the evm at the time um and since we since we can't do that with memory we have to do that pointing to a transaction does that make sense or do

you need a different approach yeah no I like I I understand it as um just a way to to get them to feature par in a way right right um in the in thect I I understand that as a nice goal although there's another way right which is you you deploy a factory first and then you do a delegate call into it yeah yeah this this way there's less stuff left on the Chain yeah so just want to understand the proposal yeah you mean deploy a factor which does an eof create right yeah well this is very expensive because the UF

create needs to well sorry the factory needs to contain 100% of the code that you're planning to deploy so so so you pay the biggest cost which is the 200 bytes sorry 200 gas per word or bite I don't remember twice effectively right and you would have to have an EA transaction in the next too yeah yeah so what would be the the proposal to put forward then um we probably need to write up a separate rather than having in the eof create um EIP we need to take what was in there for TX create move it to a new EIP to create TX create and that's

something that we can add to the proposals for Osaka is to add TX create and then I think we need to update I don't know if we want to update as part of that TX create or we just update in general um the hashing of eof create um and then as part of the TX create we could put um a couple of tow hold contracts in for TX create and then from those tow hold contracts we can create all the magical things we need with ERC I think we want to limit the number of ones we put in by mandate um one that is like um salt plus address and the other one that is just salt and from one let just salt we can deploy all the other umh Dey of what what what people would need you know saltless create that tracks the

nonces um any other guarding if they want if they want to mix in the sender address into it or not we could deploy those from there so I think it would be two to hold contracts is also what we would put in the EIP and then we could add all the other interesting factories off of that yeah yeah it sounds like a good idea we need to be very remember all the arguments for TX gr that we have talked about right now but we have the recording for this so I guess that would be we won't miss this and then uh that would be a strong case for TX gr that would be great so this is TX create the op code

the new transaction type Plus at least one maybe two is that that's specifically for multi-chain deployments well so it would come in as part of the EIP and then from that so this this uh this rip that I showed um where was it so so this particular rip um they're trying to standardize what the could come in there but if we put the

required contracts in the EIP then any chain that claims uh ethereum compatibility would have to add those to their predeployment like the eof version of what you're showing on screen now right it would be the first two and then the ERC once we get the two the two two hold the two toe holds you can create whatever standard sets you want off of those and anyone can run those

transactions because you got the right tow hold do we want to support Legacy at all with or maybe I missed something do does this ERC number RP sorry 7740 RP 7740 so what's interesting about this rip is it depends on um the addresses are what's on Main net these are four contracts that have been deployed on mainnet and it's saying the argument is you make those a pre-install with their mainnet address yes that's clear but that's for

legacy right because we don't have UF for legacy right so we are making a case for those pre-installs for legacy maybe we should only be making a case for pre-installs for your at different addresses of course I'm using this as the press to say it's it's it's been done before and it's been standardized we would make this just for eof got it okay okay so I I guess this is our this is a viable plan a maybe we should also have

a plan B which is in case there's you know we don't manage to get TX in what would be the next optimal design but maybe this is too early to talk about this let's prepar the T create proposal first um I don't think we put too much of Plan B because we are the headliner for Osaka us and pias at the moment I think we got the space to say we need to get in what we need to make this work I think the only reason we had to pull this out of Petra was the arguments that there's too much and if it's too big then we're going to be pushed after verl and after you know another series of blob increases and we

chip sometime in 2030 but now that we have um liner status for Osaka I think we have a lot of room to to move and say we need this for the quality uh for a quality solution okay okay we'll we'll I guess know in a month or or two what's MH yeah if it's feasible or not yeah I think we go along assuming that this is plan of record um okay what was the CH is there

a chosen scheme for eof create so I mean technically but this is just my writing here the scenario 1B which is TX create with irregular State change thank you does list the eof create which is hasing using the proposed by Charles Way only sender plus Sal and it's the same for TX create which grants us um code non-observability also well uh what

else well it gives gives the this is the most most flexible way that one can write the uh UF factories I guess which which has a certain M yeah well still preventing collisions between deployers yeah so yes uh if anyone so as assuming we go with TX create with an ISC if anyone has Arguments for against um the letter C in that um combination of

solutions which is if have create hashes with ketak 256 Center and salt then maybe we should uh yeah please go ahead U uh you know uh give arguments and comments and and maybe there's a you know we decide on on a different way but for now let's I guess we can we can try to assume that we do this kind of e great what we call it instead sorry there's a question from Fran you call it an ISC yeah don't just say a pre-

deoy okay um yeah let me make a soft note predy or pre-install because you have to okay I'll change I think in the um notes there was something about the um compilers should provide good defaults and um I think since there's no um equivalent to create one I think it's totally reasonable to not expose a default

salt um to the user so it's just like salt is a required argument for all I it's just exposed as a required argument of the user for all creations and actually an argument for adding a third predeployment you mean something that keeps track of non I mean it the user can do it too like it would just force them to actually do it um explicitly right but I think Pavo pointed out on a previous call that like we actually don't need nons anymore right if you need saltless

deploy you would use one of the ERC contracts probably explicitly and maybe that could be weaved into the compilers yeah I mean there there actually is no salt lless deploy anymore because there's no there's only create two well you would call into an ERC contract that keeps a knows tied to your account and uses that knows to see the salt right but I mean from the evm perspective there's no nons deploy I mean there's no deploys so it's right that that would be a solidity Viper level yeah it's an application Level it's weird for to assume your existence um yeah the compiler doesn't have to do

it I think it it just like completely forces the semantics into user space which is um a kind of a good thing in my opinion yeah we can Circle the Drain on this before we actually ship because we got at least until until June I mean maybe we the goal is to have this spec totally locked down never going to change by June um late May early June um so this you know might be the last thing we we settle on when we see what people's use is going to okay I don't think we're gonna have time to get to Osaka One spec change list is

there anything else we want to talk about on um the eof create stuff I think we got a good solution here cool um anything else we want to talk about before I close the call all right hearing none and as people are starting to drop off I'd like to thank everyone for their time I think we had a really productive meeting excited to see the ship this year uh

thanks