EOF Implementers Call #41

Transcript

recording in progress okay so welcome to the EOS implementers call um and as usual um let's kick off with the uh client updates [Music] um uh and they do want to do updates for one I don't know if there are I think even one didn't have significant updates mostly people on holidays yep I don't recall anything either um

Riley um are you with the client team or um listening or U uh I'm just listening cool welcome from from art blocks I know we we're kind of interested and just keep a chat keep have on this one so yep okay cool welcome and um I think that's all the clients today seems like there's not many people attending um Charles who just typed into the chat that there are no updates from Viper and you have a question okay uh so that's that's it in terms of the client

and compiler updates and then the spec updates we have uh the topic that we want to discuss is the version of the eof which doesn't require The Irregular State change which we touched upon in the previous meetings as well um but uh maybe maybe Charles you can you can go ahead with your question now uh yeah it's just this um P request uh so this discussion we were having on the init code mode validation in yeah

for reverts so if the question is what happens if the container has nothing but revert or invalid and um should that be banned in a nit code modeh M and my instinct is to allow it um but it would also be okay to ban it because I don't think it's very useful to only revert in create mode because you can't even tell if it's if it's revert or why it reverted but this This concerns the version uh that you're proposing that we

do validate the init code mode during e validation correct yes so it just um makes the rule a little bit more complicated which is some containers are run time for sure some containers are nit code for sure and some are like um Chimas they can be so within the within the proposition to actually validate this rule in EA validation would are you opting to allow the these containers without revert or

in with only reverts and invalids or not it yeah that's the question that's up for discussion okay um I I don't know I don't have an opinion on this and right now they designed to not validate this is kind of the Baseline design I have not given it too much thinking I think in terms of what your proposal has I would mainly just know what I was asking for is just to to be aware of what the rule is yeah so if it's allowed then I think right

now last time I looked this this proposal um did not allow for these containers because they were treated as right I don't remember exactly but they they didn't they weren't allowed and if they're not allowed then I would just spell it out in explicitly whereas if they're allowed then then you know some changes need to be made and and that's it does anybody have an opinion about this or is it like it's kind of inconsequential I don't know anyone does this also affect validation of you have create of parent in the

parent container I'm not sure what's the entire proposal haven't read the your um can you um the idea is EF create cannot reference a subc container which has return or stop and um return contract cannot uh reference

uh container that has return contract it basically um block it basically the idea is it blocks the invalid runtime Behavior at time I think um yeah I don't know I think it's okay either way like it's okay to require that init code actually calls return contract or it's okay to disallow I think so yeah it seems there

is no reason to ban it I would say to ban to ban you have create access in the container it only has reverred or invalid yeah yeah I don't right I don't really see a use case for doing that but it's also a bit Draconian to do it so I'll just um change it to more match the runtime the original runtime CTIC okay all right so then the next topic uh is the version of which doesn't require The Irregular State change so without the Creator contract it is described in

this p to the meas spec if you're interested and uh I guess there are some uh there have been recently voices in support of this for this version just to avoid the reg the irregular irregular State change and uh there has been like the first which used uh which which aimed to use the data section of the uh in it code for the data and then the change was to use the call to have

the call data being sort of appended after the unit container now this changes in the pr um I don't know uh we don't have Doo or Alex here to poer opinions but I think D is supportive of this at least of a version without the regular State change and Alex was also I think um had concerns initially but then said it's it's fine um does anyone has any other opinions

or arguments for against well I guess not um well I I will say I'm tentatively in favor of including this because I also don't like regular State Change option and like the property that with this proposal existing tooling would be used without any change and just can

deploy UF so no change to tooling is required uh yeah so yep um I'm not super familiar with this how do you get rid of the um uh the special create contract okay so the idea is to retrofit the Legacy creation transaction so when there there's a transaction with mt2 like the Legacy creation transaction but it uh starts with eof

prefix it's uh it's data starts with the eof prefix than it than the data is treated as an uh init container for Eos and that's it most mostly and how that actually sounds more intuitive to me how do you do it with the Creator contract you have to like call the magic contract and it calls TX create yes well you can call any contract that uses TX create the Creator contract it it's magic is that it's

it's it's introduced with the irregular State change if you don't have the other option so is like the thir first first your contract out there that then can spawn more e contracts so you know anyone is free to deploy a Creator contract after uh after eof is activated using these retrofitted Legacy transactions and then TX create just stays the same and can be used for its um its uh intended purposes yeah I mean I know that like ZK

sync and maybe some other ZK chains have the this magic Creator contract and I'm not sure if they considered the this kind of Legacy creation transaction type and why they rejected it okay what why do they I mean what context for the creat contract they do something similar to this um Creator contract but I don't know why I think Den might know okay okay I'm just saying that there is kind of a precedent for having the the

magic Creator contract okay though it's not on L1 it's not on the main net and I think St on Main net is is the problematic part um I also don't really see why having in a regular State changes that big of an issue to be honest it's because of well it's it's scary by itself I guess on some levels probably more on the client um development perspective and also sort of we anticipate a strong push back against it on or all core

deps for this reason yeah I think they use the the I think ckyc uses the Creator contract for something about code introspection so like I I don't know the details too much but it's something like the Creator contract like puts it in a registry when you call it puts the code in a registry when you call it which is like actually something kind of similar to UF and then when you want to call when you want to deploy that contract or deploy a subc container that contract or something then it's in the registry so you reference it by the hash instead of the code uh but why just to clarify the Creator contract you're talking about is on the L2 or all the L1 it's on the L2

it's on L2 okay I'm pretty sure it has something to do with uh code introspection and referencing code by hash but I don't know much more than that I know I can I can take a look or or if you can uh produce a link to follow uh if you can find something I have a hunch that this is a like a different use case but might be wrong okay thanks let me let me open the link and then uh let's continue um okay and I guess uh if anyone has

any other design ideas to this uh these special creation transactions that can do e then please uh comment on the on the pr that I have linked to otherwise I think the conclusion is that we are in support of this design and that's probably it for this topic do we have any other spec anything anything else all together to

discuss um one thing I found kind of interesting which we don't really have to discuss in the group but um because eof like freezes code we can actually do something really clever about storing code so we can like d duplicate a lot of code and I think um that the cost of storing code can come way down um maybe that's like more interesting in the context of how eof and veral interact do want to discuss this uh now or write it up

somewhere is it the store like fetch the code from transactions that deployed it yeah exactly I I I had a couple comments in the evm Discord but basically um the thing is like code and this is like actually something I do in Viper which is like metadata is stored in the init code because it's usually cheaper because it's in call data um and you can like index op but anyways so like the interesting thing about UF is like code can never be created from inside the evm so it's like all in transaction data and so like to

find the code for some contract you just like need a pointer to a transaction but in like in in the opposite direction of where where for force is going like the to remove the historical data and I mean I have two comments about that one is I'm not like totally sold on 4444 um the argument for it is a little weak in my opinion because um the analysis that was presented at the last all core devs um didn't take into account that it's much cheaper to store Flat data like block um information and call data than to than the state

database which needs to be uh you know like some kind of key value store and then the other thing is even if you delete Old State uh you can still store code much more cheaply in like an auxiliary database that isn't the hot database because code can't be updated and it can be duplicated as well okay I think there's something in like Legacy evm like I guess in theory you can D duplicate code in Legacy evm but it's like harder um for a few reasons like previously we had like metamorphic contracts from create 2 um we also had things like um uh yeah I

think it's just harder to do that while the evm is running but in this case all the code is coming from outside the evm so like the hash is known outside of the evm so you can store everything in like a super cheap database it should be in my opinion about as cheap as call data instead of 200 bytes per sorry 200 gas per bite but this I mean sounds interesting though I think it is like a it builds upon EF in of itself yeah um yeah it's interesting it doesn't

actually need to even be part of the eof spec it can be introduced as a pricing change later or like as an implementation detail yeah yeah yeah exactly that's all right then um do we have anything else else discuss or should we just um I guess uh end a bit earlier today because there's many people on holidays and uh and we can wrap up now um so thank you

everyone and see you next next week thank you thank you bye bye