EOF Implementers Call #64

Transcript

all right I'd like to W welcome everyone to the 64th uh e implementers call it is the 8th of January um on the Western Hemisphere at least um our agenda testing plan updates compiler updates and then spec updates um mostly dealing with some things we were finishing with um in December got some open questions there um so first testing update do we have Mario on the call yes we do yep yep here here I am um not that much anyway uh to to update from testing um there's a couple of PRS open um there's one that needs the attention from someone that is not me because I already approved um but

if you guys could take a look and um yeah this is one um if you guys take can take a look there's an open discussion on uh that has to be resolved that I think it's very simple and I think it's already resolved but just to confirm and that today y all right yeah I'll get the conclusion on that um is it the bit about the Preamble code exactly it seemed it seemed fine to me I mean um it sounds reasonable so I don't have any objections but if there's anything else to discuss yeah well I wrote it so clearly I'm okay with it so maybe we should get Peter to approve it and close it yeah and then we can move on with it cool um fuzzing um I ran fuzzing for

a weak solid um apart from a few bugs that were found um it ran clean for like a whole week um I didn't have nether mine because nethermind has an issue with output I had to run it in the mode that had no tracing output um because the tracers have subtle differences and it couldn't diff the traces it was only testing the end State um so I needed to take nether mind out of it but I've you know read nether mind for a long time as well um but this includes um ref evm one Basu and G um so from from the fuzzing uh strategies that I have which include introducing new random op codes um things are things look pretty well U and I'm learning some of the boundaries and I think this is a good sign the boundaries of the testing uh framework

for example evm one requires uh exp mod pre compile if that doesn't get turned on by default so I had to figure that out um and a couple I found a bug and Basu um that resulted in a new PR uh one of the new ghost tests um before we did the the Clean Run and bunch of these are mostly boundary testing um between the various uh versions um I haven't pushed up my new findings on here but it's uncovering some other edge cases that are probably General evm issues like how do you handle calling an account that has a max un 256 ether do you roll over and lose the ether or do you fail not a

real roll situation that's not going to happen on Main yet but it should be clearly defined so there's going to be some interesting things falling out of this um cool uh anyone else have any comments on testing before we move on to the client updates okay so just checking just checking the state of the PRS I think everything is merch said the last one but yeah yep Yeah well yeah that's yeah that's the one where we had to do Thee the three Amo test case the yeah the Preamble code and the gas testing okay um so share this link yes

please I'll go ahead and put this [Music] um add that to my notes okay um next is client updates um I'll just start with the go around does anybody any client have any they need to talk about or any information about their client that's changed over Christmas probably not um so Basu nothing to update nope okay um not seeing

Reon um not seeing gu on either evm one anything to update nope and nether mind any updates there uh need to do a bit of uh work to bring our Branch up to date with uh master I mean with pectra but otherwise okay okay and that's my um next main point we need to make sure we rebate off of Petra 5 um and that's to get us ready for um the first real eof test net um there is

some debate whether it's going to be called eof devet zero or Osaka devet zero and that's probably a question that needs to be answered in the alore dev call um but I think yeah um NE mind that would be good I know gu will need to rebase theirs Bas should be good um I don't expect anything different from them and evm one um you're ready to um run off of a pectra 5 that would be an eron V3 um no not yet okay um to run the devet we need at least three so I could

get gu up probably here in the next week and um re is the last wild card um I don't know if reth runs off of Hector 5 yet either let's see okay um next agenda item spec and other issues um got a solidity update here um left by um um R laav um so basically the update is that the solidity support is going fine

um it's that on schedule um he gave a list of everything that needs to be implemented um over here not over here over here so here's uh hit list uh basically a punch list of all the random things that need to be implemented and fixed um for the final result for it um so if you're interested in reading about this um you can read all the details on um we don't have Charles on so no Viper news any other compilers just to know that I think this

is the least for things that need to be done before eof supporting solidity is not experimental anymore um so that's why it's so long I guess but I think from what R has posted it is functional so it can compile okay now um this is going to transition in a spec remember we had um in November we had a list of small breaking changes we wanted to do um I guess one question would be how would those impact e the uh solidity support um things like reordering some of the op codes um I mean I think Ric at one point

commented on most of these changes and I mean he was aware I guess okay and I don't think he he panicked in any case but it's going to be um very impactful maybe this hashing change would be the one that could be more uh if we if we go uh if we pick one of the more involved options I guess right okay and uh argument argument order not the name of the op code not

impactful data section index not impact no the I I don't think those would be big changes those won't be too hard um cool because I'm you know we're ging how we want to do that because if we want to ship Osaka zero what we would have shipped inetra and then we do Osaka one or devet or eof devet one with the new slate of changes then that would change which eofs compatible um which which solidity version we would use and I would think we would want to get all these changes done before we flip the experimental flag off of solidity so that's probably how we would want to run that my godfield tells me that the non

the experimental flag on solidity is going to get uh removed much much uh later than any definite that's my gut view but I don't want to speak for the for team I think generally that will only be removed once it goes live may not yeah right not even test net main net yeah exactly that would be my go feeling okay cool any other things we should

talk about for the compilers before we move on to spec issues um there's the issue of the um sort of Syntax for the exchange op code I don't know that there's any consensus really um I still consider it important okay this would be in their Ule section I mean this is not just for solidity it's any right any language assembler disassembler do we want to spend time on

it or just mention it needs to be fixed and work on it in um the forums not sure I mean I I wrote a document about it I would invite people to read if they haven't um I don't know if others agree with me that this is important I'm just concerned that we will have like off by one slightly different syntax over all over the place and it's going to be very confusing right maybe just a quick temperature check do do people consider this important or entirely unimportant I think it's

important long term maybe from terms all okay like I guess this is shortterm important for you because you're writing the assembler right now um I think it's important to to have a buy in on whatever is the syntax because if one language changes it that that can cause like a lot of issues and if you know one person is extremely feels extremely strongly about it and makes that change in that one language and if that gets picked up and we do have a trouble in our hands so how's that g work with swap one

and swap two just a sec is there is a swap one instruction or is there not yes there is like the a swap yeah there is a legacy 90 swap one um so the question is when we do the um the immediate swaps do we stick with swap one means n plus one or do we go back and say that swap is I mean that's it leaks over to swap as well yeah to me changing the syntax of swap is crazy um it's like a loss cause I I would just focus on Exchange and if we want to I mean to me even having Swap and Swap n have the number

mean a different thing is crazy uh I would do it like a different name but we're not at the point where we'll change any op code names so mhm there one uh one cautionary t uh tail here is the return data copy uh was you know it was one of these examples where people tried to change the semantics to something they felt like is more reasonable and hope that the rest of the system would would move towards that it never did and uh you know return data copy was this one exception which behaves differently than the rest and now we have changed that or wanted to change it to UF um so I I

guess that's you know maybe something to look at if if you're trying to do this we're trying to do the new instruction properly because we think that's the proper way it should be but if it becomes inconsistent with the rest we may have like another return data copy situation down the line but it is about the assembler syntax it is but you know it's it's semantics uh people need to be aware of it and the whole goal the whole idea why return data copy uh wasn't zero pading because a lot of people felt like that there was like a

bad design and they wanted to fix that and it ended up being you know this single one exception and you can apply the same logic to the numbering if these other instructions leave differently and then this one follows a very different logic then you know maybe it will end up in a similar position downend the line well the thing I think is that dupe and swap already are inconsistent between them so yeah so it's it's not like we can just say exchange should do the same we have to choose between one and the or the other I would just propose to to go with the approach I

called exact in my document um but only for the exchange off code and maybe people can think about that and if we agree which is push that wait so exact for ex exchange and what for D weapon oh uh traditional traditional but that one I I get it is maybe more controversial I don't

know I mean that would be my final proposal just to have like something concrete to go forward on I mean from usability and um solidity assembly I think exact is good and we let solidity do the magic of encoding it um because as far as op Cod codings um evm is quite straightforward you go to other systems like epbs and uh ebpf and it gets Qui obtuse so having assemblers do the magic is not out of line but I still wonder if there should be a way to escape into

literal um with syntax yes I I mean that's nice but I don't know if it needs to be standardized or do you need to be yeah yeah the syntax can be customizable everyone does exact and if they want to do the Escape they can have an assembly specific Escape into verbatim right and then you can have like um numeral symbol hashtag X could mean different things in different assemblers at that point we don't care yeah okay

okay so we should probably all read this and come back with a stronger opinion in two weeks and I think if we set this in solidity it'll be you know the first assembler out there it'll be easier to get the others to follow on so I think it's whatever we decide should be what's reflected in solidity unless the solidity team's got a stronger opinion yeah I mean and also we can because um East also has as like sort of assembler or DSL and also the specs kind of you know hint on what the syntax could be so we you know if we have a reasonable starting point then we can also apply

that it that approach there and uh hope that another other assemblers will will uh play along and I think it is actually doing yeah uh East is doing the exact syntax exchange 23 becomes e800 so yeah there's already one vote in favor of okay all right um any other compil

assembly notation issues before we move on to spec all right let's move on to spec first spec item is the UF metadata section um was there any followup on that EIP we hope to do any M1 like Spike implementation in ev1 and also some uh example tests in East for this but but we didn't have the capacity this is fre

7 7834 if I recall correctly yeah uh and did this include changing the uh the data section to section FF oh

um that's the smallest of we can them orthogonally I think okay all right so the next any Last Call on metadata okay next one is e create DX create hashing and there was a doc written up about this yeah so so to comment on this dog I only have been able to prepare this today so maybe it's best to discuss it on the next call when everybody has had the chance to

familiarize familiarize themselves with uh basically it tries to sort of summarize um some options and uh some potential you know ways we can tackle this and organize them into those scenarios that you're we're looking at right now and then uh makes a sort of an attempt to compare them in terms of what they offer and how problematic they are uh so I invite everyone to take a look at this document comment and uh unless anyone has any quick feedb feedback right now we can postpone the

discussion till um uh till the next call and this document covers both the uh UF gr hashing and the question about the terministic deployments yes yes I I decided to combine them because from this um thread that we have had on GitHub it seems to me like they are kind of interconnected um I mean it became apparent that um the schemes that we have have been discussing for EF gr do not uh do not solve the deterministic uh like all this all this

family of of uh different kinds of deployments that are being used right now uh so maybe it's worth to take a step back and try to look at it from a broader perspective so for TX grade this is going be comment um is there a reason why we're not including the TX hash that comes in as part of the app code as part of the hash the TX hush sorry so TX cre you need to reference um something in the transaction and I think one it's either linear index or a hash of whatever is in there already to mean in container hash right yeah in the transaction

object so in the container hash um is there thought of putting a nit container hash into the TX create hash but not the eof create hash um wait uh so the last the most recent design of TX create uh I think it included the init container hash mhm uh I mean this can be also considered as one of the possible um Solutions and scenarios here but there has been a proposal to leave this out because it can be included uh into the salt by the

factory code and uh okay so it becomes a factory responsibility yeah I mean if there's a yeah and if there's a you know compelling reason to have this then we can of course discuss this but for for for the sake of not not having too many options um those schemes for TX grid and um you have gr here uh for TX gr sorry they don't include the in container okay because over Christmas uh in the Discord that kind of leaks them to the next thing I wanted to talk about for it which is the uh proposed

contracts so if we know that we need to put the TX has in it um then we just need to do some more math on the salt here um my pitch of the deterministic deployment factories presumes that the hash is in the salt um and we it wouldn't be too hard just to write it to include the hash into the salt which would just mean you know another KCK inside of here um which isn't too bad um we KCK with the salt to make sure we don't get collisions okay well is not mentioned in the document I think but if we leave the init container has out then maybe we can save uh on the

hashing cost which is included in the deployment cost at least for E cre that is the case for TX create maybe well it would just be hashing over um 64 bytes 32 for the salt and 32 for the code hash I'm calling it code hash here so it wouldn't be it's it would still be a full check round but it wouldn't be over a large amount of data and I think that's really what what burns us at runtime is hatching over the entire contract and that would be taken care of in the transaction processing with the code has hold on for TX create you need the code hash anyway it is provided the Cod data so you don't do

not need to rehash this then you end with all sorts of weird pattern by devs to try and avoid um the unit code hash affecting the contract address so maybe it's better not to include it I mean yes and and this document I don't think it goes into detail on this but uh it has been discussed in an issue that is linked from the document and this big issue so one of the reasons of including as little as possible in the hashing schemes there is to um leave leave the

choice of what what is affecting the address or not up to the application layer right so we would provide a set of standard contracts you don't like it you do it yourself which is just address plus notes if you don't want the code hash you can write your own deployment Factory yes and and it's and there's many other elements that that the schemes either w't left out or included like the input or the nons or uh one more I don't remember oh yeah the init code has the input and the nons and I think there's right use cases for including or excluding all

these right because in this this this default version I don't include the init uh the init data um you I just you don't have any init data that you can pass in and some people might say well I want to do that so that's just basically you know haggling over what the defaults are going to be and then it gives them freedom to change it yes I mean of course it puts the burden of providing right defaults on probably the compiler um this this goes more for E of create of course right because they need to handle new contract something something um oh yeah e great would need to worry about it yes so so and this also is discussed in this thread and um

and I tried to capture it in the comparison but um all feedback is very well welcome on this I me there could be I mean this is like practically an open Zeppelin Library you could have any mix and match cop you want you just bring it into your system and there's recommended defaults it get steep pretty quick I mean you're giving them the power to do it yeah we need to worry about best practices so yes um please take a look at the doc and uh and also uh I encourage everyone from the application layer and

compilers teams uh which I think showed up on the last on the previous call to take a look look and and uh provide feedback okay anyone else have opinions concerns support I haven't read the document yet I'll I'll have some thoughts when I do that okay thanks kind of addressed PRC and the last two items getting back to work and mountains of paperwork they

been doing this week I haven't had time to enumerate these um but the last two questions are the three the work on the oaka one spec changes and that's the smaller list that we got together um probably should have enumerated that I didn't think we'd have this much time left after all those all the stuff before this after the last meeting um and then the temperature check on timeline so um maybe I'll start with the temperature check and then we can loop back on to the minor changes uh what are people high level wish lists for when does this get activated on Main net um without concerning yourself with the rest of the chain and then considering yourself rest of the

chain do we want to ship it this year ship it next year this year with TX create next year with TX create um eof what people's eof yeah when we are comfortable with the design yeah when I mean when when the final for me it would be like when there are no more deal breakers okay and I'm hoping that would be this year well I mean it's not going to be shipped

on Main this year there no chance but 2025 yes I don't think there'll be another hard Fork after Petra right yeah because Petra is looking at Q2 right now but if we could pull off a small fork with just the would people be on board for rushing that or do we want to just fully accept we're going to be in q1 at 26 i' accept that I mean I think that would be ideal small works yeah I mean if if we

could couple it with p d you know that would be great right but if if that's going to lag it I think it would be better too well I think it also depends on how much P dases didn't lag yeah and then we could you know it's easier to get in um without too much without the fork plating whereas if if it's going to be next year then it's going to be a large Fork yeah okay so nobody with strong opinions because this is certainly going to be a discussion in

atds sometime in January um just want to see where people's opinions are on this um yeah it's there's nobody's got a strong opinion of when they want to ship Osaka anyway it sounds like outside of eof or inside of eof so we're see how it goes about I guess all right and Peter did you have that a link to the list of the small items that we enumerated yes just a second okay you mean this

one mhm Dan if we have a second could we we elaborate a little bit on why um we think it's best to tie with PS I I I think it would be nice to to tie it with pias but I don't know that I understand the um compelling association between the two uh to just to Fork the the L and the L at the same time rather than okay but I mean it depends you know if we're if we're ready to go and P is going to be you know more months then it's worth probably getting

ahead okay thanks yeah but the these features aren't as tight together is like say the first Denon where withdrawals and blobs where there absolutely had to be synchronous changes that's right okay so punch list see if there's anything in here that um so Max St height this would involve renumbering um basically some math instead of doing Max height you do

Max height minus your input this would impact the eof format it would affect validation it would impact um fing as well but that's that can be dealt with eof create is reordering the stack and I would assume TX create to I think TX create is spec would need some reordering we haven't done TX yet this is yeah it probably is affected by the same issue e cre this is actually a separate issue that's been escalated because it's pretty big yeah we can we can put this actually off this list maybe I don't know maybe not

now that's that's fine um and return code oh just changing a name this does affect this the compiler that's a small one that would affect solidity and then finally change the data section from 04 to FF and probably retire 04 friendo yeah I just realized here we are also missing the contract type up code oh my goodness yes we are it was like a more big uh it is not on list because it was bigger that's that's the main reason but is it also considered for E

V1 I mean for the hard Fork I think so I think uh we still wanted to sort of gathered the arguments for not um including it in uf1 but not done yet um and I'm just remembering from the R&D session it seemed like everyone who wasn't a frequent attender of the calls that was in the euf section they were warned to the idea of making it be a contract type where zero be Legacy um you know the different values would have different things one would be eof contract two would be delegate call so I call a delegate contract so they

could identify it oh yeah and also this not it was not on this list and it's sort of not comparable to those small updates because it has the advantage of being possible to introduce later right account type I think is what it was there there's an EIP um I have to search for it but that is a must ship as well 61 I think yes yes something that and I think this one is just has code right now but I think from other developers other core devs there support

for getting it to account type um which would solve most of the EXT code problems but not like um EXT code copy and EXT data copy but it's pretty established that if this isn't in there people would just create a set of standard um redirect contracts to get to the op code and return it as data so yeah it's it's a should have not a must have I think is what I would phrase it which one is that should have uh 7761 we should have it but it's not a

must have like um anything that would require a breaking change because we could introduce it later if we get it wrong but it's better to get it right so I think yeah yes this one of things I I disagree on just from the application layer I I see it as a must have okay it's a deal breaker till it's in probably how you would view it that is my position but I think fair and I'm fine with account type I

think it does address most issues sorry but but the main issue is with the erc721 contracts uh correct so there's two things motivating at the 721 um because they specify I mean I specify you're supposed to check code size but we with one to make sure is that it's a contract that accepts a call versus an EA and using Code size as a proxy for eoa um I think the open Zeppelin folks were coming in and they were concerned they wanted to make a new type of uh maybe not make a new type but they wanted to make sure that their proxy contracts if their proxy contract was an eof compiled contract they wanted to make sure that they had the code in there to prevent

you from accidentally sending a legacy contract to the delegate locking it in so they would check the account type before they accept the delegate and lock it in and the argument there was you just do a test call um but if we have to have it for 721s um then we may as well um leverage it for the deploy contract because there's you know there there's it's all it's it's almost all win no loss to extend it there I think is the argument there yeah I mean I regret that we or I haven't had yet the capacity to write this down but the argument was that it it I mean that the ERC 721 tokens could

um if they want to leverage e they could uh I guess deviate from the standard or you know upgrade the standard and use a newer one where where this requirement requirement is not that um necessary uh but I don't want to jump the gun without thinking this through properly and writing it down I the argument was that this ERC 165 would be a pretty good approximation of what uh what the has code is accomplishing I mean they um yeah calling it though and who knows

what traps they have I don't think that's viable but I wouldn't mind seeing the proposal and and evaluating it okay it was hand waved on Discord I think uh that was around the time when we were discussing the AA implications of this but um I would also trigger the fullback method wouldn't it if I recall correctly the only like the contracts that would be problematic or maybe put put it differently the ERC 721 recipients that would be problematic

would be contracts that cannot accept those tokens and they have um they do not have a throwing fallback function and and they do not support rc7 um sorry ERC 165 or do not you know do some nonstandard stuff with with pretend they do but they do not but again um my me memory is not not accurate on this yeah um but my understanding is like the nft storage NF Community the

safe send with make the contract checking is a is a must have so if we don't have some sort of account type checking facility and would once it need to be sufficient I don't know if they'd accept it um then we would not ever have nfts and I'm presenting that as a bad thing to be clear okay um I think that's the summary of the issues we need to work on um I guess for the next meeting we should review the hashing

document um we should get an update to the account type viip that is I'm on there so I can update um and what else do we need to and implementation on the metadata and getting us up to I think the top thing we need to work on though is getting stuff up on pector 5 so we can get the dev net momentum started yeah um and review The Exchange okay any other questions or comments uh for this call First Call of the year

all right if not this is going to be an exciting year um I think it's the year we get stuff if not shipped it's going to be so far down the pike that it can't be stopped so uh yep like to thank everyone for all the time and effort they put into this thanks