Verkle Implementers Call #20

Transcript

hello this is veral implementers call number 20 and issue 1089 in the PM repo uh starting off with any client te updates anyone want to kick things off this week uh I think that can go first so yeah so in NE mind I was just trying to test the wal syn implementation and last week I was able to uh implement the healing part uh and test it on C and everything seems to be working fine so we can so like anyone can just join question and now uh using wal sync I don't think so you'll ever

use the healing phase but in my testing I modified something things and tried healing as well and that part also works so yeah um yeah for GU uh well there was work on the testing framework but uh yeah I guess Spencer will give an update uh we did a lot of work on the spec um there's still an outstanding PR from giner that unfortunately I didn't get around to uh review just yet but they will be done today um and then we started the

implementation of the uh new uh 44762 the one that we decided on in in Kenya U so we we haven't uh yeah I I just fixed the the last few bucks so I'm going to give it a run for the test and then we will need to to run the testing framework again to make sure nothing breaks and we've been busy with measuring uh gas and Witnesses we don't have anything to publish yet but we're collecting we're making some progress collecting data so we'll have something uh in uh in a few weeks uh Ino did I forget something um no um particularly maybe

mentioning that I have almost ready this analysis that I've been doing regarding the code access gas impact um based on mainia transactions and also uh comparison between the current 31 byte Cold chuner versus the 32 byte C chunker proposed by the ipsilon team um also based on many transactions so uh we are wrapping up some details and I will share this document in the next days so for others to check anyone else have any updates i''d like

to share I think uh kareim has there we go I think he's just joined with his mic hello hey K hey I was going to give an update for you but it's probably better for you to give it yourself okay uh yes so still working on the flat DB so I'm trying to do the refactor of the pl D in order to have something that much more the V implementation based on stem Etc um so not a lot of news since last week and is also looking how we can save the different veral data

so trod flb Etc in order to reduce the size of the database so yeah looking at some optimization Etc we also had some um performance optim we also added some performance optimization something we already have with Patricia merry so it's it's a way to preload the the the tree node during the block processing so like that at the end of the block when we have to compute the state root everything is already in memory so yes we implemented that in order to have also this mechanism for Vel and also a mechanism to precompute the stem during also the block

processing um yeah in order to optimize the the the the final step in the blog processing to the state Ro computation it's all on my side cool anyone else any update on the testing side of things that we'd like to share

today yeah so um thanks to G we now have a successful uh framework so we had a kind of a small bug that was hard to find that h g pointed out so uh thanks for that took me a while to find um so we now have our first uh release can just post it in the chat right now um so these are the simplest form of the transition tests so the type of transition tests are mid Fork transition tests at least that's what the term we're calling them

right now where we're filling all our existing tests where the test block starts on the fork transition block and these um are being filled with zero strides um and yeah so if anyone wants to try this out um just make sure you have the Shanghai to prag at time 32 Fork enabled it's mentioned in the release and yeah hopefully you guys can can test this out and if there's any issues with it then uh just feel free to ping ping me or Mario and we'll be happy to help um as for the next steps for us it will

be filling the Genesis test so starting at the vertical Fork um as opposed um during transition and so this will be updating our framework to fill the tests that ignasio has been adding um so yeah that's uh that's one point um there was a a small thing um or just a question that I guess we wanted to bring up and it's kind of a specific question um in relation to I guess how how we can debug uh main net issues in relation to whether we want to

know I guess the specific account that has the issue so in a in a post viral world where we have just the veral tree will we need to know the exact account where an issue could reside or will the verical tree be enough and um maybe just to follow up on that and from our side when we're filling the transition tests ideally what what we'll do or what we will do is create a mapping at the start before the transition occurs of all the accounts and we'll create a mapping of those accounts to get the the stem in the tree and map those

to uh the vericle tree stems so that if we do have an issue when filling a test we can look at this mapping we have and index it back to the account so if um if this is something that's necessary I think it could be something we could look into um yeah I just just wanted to ask that question if that made sense uh yeah that makes sense I think was I not dumping the mapping at some point and maybe we removed it but we can add it back uh we could do this uh oh no there was a tool that would create the

mappings for you yeah that's the thing um but otherwise yeah this is how I debugged I just look at the veral tree like the witness and the veral tree dump tells you everything you should need to know if something is missing then there's a bug that's that's a bug in itself um but uh but yeah so far it's been working great because this is how I debugged everything so just looking at the at the output the V vkt output and input should give you all the information you need and if you want to create a mapping that's also possible yeah uh I can help you with that if you need no thanks I don't know if uh Mario you

wanted to mention anything about this we can't hear you Mario if you're talking maybe some mic issues can anyone else hear Mario nope okay we'll see if he uh comes back in a second uh sorry go ahead you had a question no go ahead go ahead uh I was just going to say small things Spencer

you uh if anyone wants to get a hold of you or Mario any uh preferred method for people to get a hold for with any sort of questions I think Discord Discord is is good um I'll post the release in the vertical tree migration Channel if that works for you guys um and then if anyone has questions they can just reply to that awesome thanks Mis uh so I do have a question hopefully it's not too long we are going to try to merge because we have like maybe three branches different branches uh I'd like to turn everything into one I fixed the issues like the incompatibilities between at least two of those branches if not all three uh

when I want to test those br is is there an easy way I can do it with that new release uh yeah so um the easiest way the thing on G would be to use the evm block test command but we have um the consume rlp simulator which we're using uh and uh we we we have a CI setup it's just the uh it's kind of broken on the server right now this is my fault but it's a easy fix so we can uh we can just start running clients on the CI

um but uh otherwise I can uh send commands to to test uh with the fixtures I said in a similar fashion to how all clients are running tests right now um um I have a small question for you Spencer so do you think it's a good idea that I replace my Branch with um peral Genesis tests on top of this release or should be another Branch um yeah maybe the the veral main

branch would be good right now I can send you I can send you it um over Discord cool anything else on testing anything else on testing got a little Echo little Echo Mario fixed his mic Mario fixed his mic but did Mario say anything or is it uh

just uh repeat like is it is it just the monitor that does an echo or something I didn't hear you twice so I think he's he's probably either muted or fixed it I guess we can keep going and we'll see if Mario comes back again cool um okay uh Gom next up you had updates that you want to share I think on couple eips 7709 and 2935 right um yeah I need to so I created uh two updates to the eips uh there's been a few discussions that were uh okay something went crazy

with my mouse and now one of the tabs doesn't want to uh yeah okay so it's going to be pretty bad to to share Windows uh okay maybe I can just do it this way sorry for the for the mess uh this one yeah um so I uh created so yeah uh there's been on ACD and other channels uh there's been some push back again relating to the fact that um we don't behave exactly like 4788 and potential other uh prag system

contracts um they are uh I mean it's really a nitpick but the the conversations has some of them have been fairly Fierce uh so the agreement was that to try to settle everything down we have uh agreed that uh we will in prag 2935 will uh behave exactly the same as 4788 so that people are happy and when they realize that uh yeah it's not going to work in veral uh they will change their minds and to that effect uh I have created did another

EIP uh let me look for it because my window went crazy uh sorry it's 7709 right so there's the an an update to the 7709 EIP that does basically the reverse of uh of the update 2935 does so it says uh contract execution is no longer f favored over direct State updates that's roughly what it is so for your information please have a look uh tell us if uh there's a problem U it's it's really just going around the nitpick uh a very sticky n

nitpick uh but uh yeah it should not introduce many like any issue um just have a l please give us some feedback and if we don't see any opposition in the next week uh we'll that in fact I will probably mention that on act next Thursday and uh and yeah if we don't see any opposition we can we can merge this uh yep that's pretty much it cool I think there's a question from Dano in the chat okay even though the smart contracts are recommended do they still need to be in place um because this

resun this testing Corner cases where if the contract has no balance has no Nots has no code any right to the storage it's supposed to be clear it is an empty contract which isn't going to be the case in veral but until then pre veral we still have the empty contract rule yeah so actually uh that's another thing I need to prepare for Wednesday for Thursday sorry uh deactivated 158 there's a good reason to do it in prag and not in Osaka uh simply that if you for whatever reason people decide that they don't want to do the overlay method they will have to replay blocks like the what I call the counterfactual history or the revisionist history and this EIP 158 is

going to cause a lot of trouble in in that uh in that case uh so yeah that's not answering directly your question but just uh just FYI um but so to to do this uh sorry I kind of lost track of my thought what was your question again um it has interactions with the uh empty do the contracts need be in place for the syst contract to execute or should contract make sure that the address is just not empty right so one of the changes in that EIP says that if the contract is not there this is considered a book so it's it's it's an invalid Genesis config if the contract do isn't

there okay yeah good and with the transition fail if someone doesn't have the contract or are you doing IST for the contract well the contract is uh will fail yeah I mean yes it will because you will need to update okay the transition per se will not fail it will write to this contract and this contract would be uh would be missing so the the right would cause an error um but so no block would process and therefore the transition would fail because the chain would Hal by rule

right uh yeah I mean if if it's not there indeed like the I mean let's assume a uh if it's okay if it's missing on a test net if I understand correctly that's your question because the contract will be deployed on Main net as part of prag or Layer Two or Layer Two okay fair enough uh so if it's missing then yes the blog processing will fail so yes it will uh like you said it will uh it will not work so that would be I think it would be safer to say instead of it fails that the smart that the uh system Contract Processing does not occur if the account is empty uh but so how do you make block has work if the system contract uh I

mean like yeah that that breaks block hash so that's why I'm saying if the contract is not there it's considered a a bug like a a configuration bug true um all systems are still going to have the cat for the 256 block has op code you don't have to use the system contract for block has unless you want to go past 256 yeah so unless unless the systems are also going to remove that part of their block hat code right but yeah exactly if that's uh if you do this that you simply don't have 779 implement mented and your implementation of verco is incomplete I mean that can be your choice if you want to do this but then I would say it's

your problem you're just not compliance with the with the with the EIP the vertical EIP yeah I'm just concerned that as specifi that it sets up a trap that's going to break some some L2 that doesn't think through it I think a more forgiving rule like you know either not writing it or another alternative would be to say that if the notes is zero that the notes get sent to one or some other field must get set to will keep it from being empty which gets in the way of deploying the code but or yeah or then that gets us in the IST I mean that's those are the issues we start getting into if if the um um if we don't get rid of the empty contract rule so yeah these are some things we need to think through and that if we do it this way before veral then

we would have to get rid of 158 because the Alternatives aren't looking good because there's always arguments on both sides of it yeah I mean yeah like I said I would like to get rid of it in prag so that would be the that yeah that will be a discussion at ACD uh I think they have to go in together I would think they have to go in together that if if you want to move away from doing the contract You' also have to do that with 158 both have to go in I think right uh what I meant is 158 would have to go okay what I was suggesting is that 158 goes first but yeah they will have to go in together

for sure like they will have to be activated at the same time for sure yinder yeah just to add to this discussion I think uh my opinion is that uh even in the current eips we should make it mandatory that uh the contract is deployed before the EIP is activated uh so which is sort of contention that uh uh there's some push back on this particular requirement uh for the for game for this scenario that you know they could be no contract while the EIP is activated and as of now I think all

the ethereum JS for example treats this as a block failure but as you have mentioned it should probably either we we change the behavior to basically say that okay if there is no contract then the entire update mechanism or for example if 7702 is also not deployed then you don't pull any withdrawals so we we we don't have that kind of clarity as of now because for example etherum JS has implemented it as a failure of uh block processing if for example uh the evm call to the contract fails right so uh evm call if there is no uh there is no contract that is out there and we

can't find any contract code C to execute similarly for 2935 and similarly for many other system contracts that we have so uh I think it is actually prudent to make sure that uh EIP says that the contract deployment is required but this is sort of uh contention Point uh that has come up and right now the there is some opinion that says that uh EIP can be activated without the contract deployed and that is some that is sort of causing this rewarding uh that is out there and I think veral will basically make will mandate that uh that that those sort

those sort of chains where the contract is not deployed but the EIP is activated our buggy chains and we sort of introduce this requirement Behavior into the eips right uh yeah I was just thinking actually I think I I missed I had missed denos point and I realized that when you said it um yeah if someone does not deploy the contract but use 2935 with EIP 158 deactivated then uh I mean yes in my view it should be considered buggy but

before people realize 7709 uh 7709 is activated then they could have their own uh they could have their own scheme that would kind of break this uh yeah I mean I I agree we should consider this buggy like right off the bat uh but that's going to be a tougher sell on on ACD um okay I guess it's worth asking the question on acde and see and see what people say cool should we keep

going next up in the agenda actually gam did you have anything that you wanted to chat about with the test net relaunch or did we decide to skip through that uh yes so I until just a few minutes ago I had completely forgotten what I wanted to talk about which was embarrassing but actually the question I wanted to ask is do we want to deactivate EIP 58 on the next test net I wanted to find out like I would be uh happy I would like to do this on the next instant of the test net uh I'm just curious if other people are opposed to it seems like no opposition I think felic

has voiced his support for it as well yeah okay then uh all all of the accounts that were that this was meant to clean up have all been handled is that right ip58 and there's not a way to create new new malformed accounts in this way uh there will be soon if 7702 depending on how 7 702 uh is built but um yeah in that case they should not be uh they should not be deleted so yeah uh that's that's the argument yes it was a temporary measure that is no longer necess necessary yeah the only people I could

conceive of objecting to would be people who are around for those Shanghai attacks and I think everyone that's still active as Express support for it so I think we'll be good cool let's keep going next up uh there is a proposal around the transition and pre-image distribution from bass folks I think maybe Gary and others I don't know Gary if you have want to yeah I can speak to that I think Karim has got some of the some more

interesting justification um but uh yeah I started re-engaging with the vertical transition after after working on uh some unrelated Eeps uh and I've been approaching the the vertical transition with the expectation that it's going to be probably longer than a month that the transition is going to take um so I was I've been expecting that I I was thinking that a month is going to be too long to not and not have clients able to say via snap so I had been approaching this with uh the notion in mind that we were going to need to support clients using snap one and snap two in order to get synced to the network during that

transition period so um think that might not be something that we've considered so far that I I think yum uh you had mentioned that we just would not do anything but uh full sync would not be capable of doing anything but full sync during that one month period is that kind of the case is that accurate yeah I mean the argument being that you would have to develop an algorithm a sync algorithm for a period of one month or two months make it make it two month um and uh it would increase the complexity by a lot of the fork by a lot when you can just do a full sync and doing a full sync unless you're really

at the end of the fork of the transition period even then at the end of the transition period there would be like two hours worth worth of full syn so I don't think it's too bad yeah I was thinking I mean even even taking a a full sync approach from the point at which we freeze the Merkel tree um that seems that seems like that's reasonable it could be slow in some cases uh but what I was more concerned about is a client sinking from scratch with no snap State at all to do the transition like how would they how during that one month period are we just not going to be able to have clients do snap one in that period with the Frozen Patricia Merkel tree right so that's the thing uh you would do a snap sync at the

last miracle Patricia tree block and then you do a full sync from there okay so we're going to continue to serve snap one even though we'll be further than 128 blocks from head with the with the frozen tree okay that that's that is reasonable um kareim do you want to speak to specifically including the the pre-image keys in the execution witness um I I can I can't really speak too much to the parallelization that we would like to be able to do with that I think that You' do a better job of uh explaining the the benefit there of having pre-image keys in the execution witness are you still here Kareem

me there you are sorry uh yes wanted to say that if we I think Gom you already said that you are thinking about that but if we have the the address we are touching and maybe also the slot we are touching in um each transaction so we can have this information stay this it it would be a way to maybe uh do some p ation when we want to import a block as we know what kind of transaction We Touch maybe a specific address and another we not touch the same address maybe we can paralyze two transaction and it will optimize uh the import block step so I was thinking if we can maybe

add this kind of information um yeah uh okay so my understanding is there are two things here so yes regarding the parallelism implementation I'm going to work on that spec change tomorrow I finally I'm at a good at a good location where I can actually stop and write more spec stuff um and uh yeah it would I mean in my in my proposal at least you can always we can discuss it at the next Vic or before but we would just add a bitmap for each transaction to uh for each uh stem to say this is the transactions that it's been touched in so this way you can schedule

your execution in in a different uh in a different order now um the problem is that uh indeed you do not really know which address uh a given uh given stem corresponds to uh which still is not too bad because you could schedule all the transactions together and when you see that uh a transaction has been scheduled like you access system that has been scheduled in a different transaction you can halt or do uh yeah maybe enter a critical section or something um but uh my understanding was that there was another reason why you wanted

to put the preimages so on top of the stem you you wanted to put the in the witness the tree address sorry the tree index and the address uh is that for parallelism you wanted this or was there a snap sync related uh yeah reason for that on my side it was foration I think Gary wanted also this modification for SNAP sync implementation yeah this is kind of like the convergence of a couple of uh concerns and the like you said go it's it's going to be a short uh concern during the transition where like if a client snap syncs during the you know post Merkel uh Merkel tree free

they won't have the pre-images that would have occurred uh from the freeze up to the point at which you know they've they've now snap sync to the network so there's like a a I guess there's a bit of a trust assumption or a verification problem uh for playing blocks you playing the transition blocks forward knowing what has been transitioned and hasn't been transitioned in terms of the key space u so that was that was really the concern about the pre-image distribution for the state uh post freeze but prior to finishing finishing the the transition um I think that that's since that's a bit of a short-term concern um I think it it was more interesting to

approach this from U like a parallelism angle whereas something that we could leverage during the transition but still would you know pay dividends post transition in terms of being able to do parallel trans transaction execution okay understood uh yeah so let me just write this uh spec tomorrow share it with you we can see what you guys think the the biggest push back I have against this is clearly that is going to make the witness much bigger right um we could shave a little by not putting the stem in in this because you have all the data you need to recompute it uh but it's still going to be twice the size of the

stem about um so I would be against it I would love to do without it but yeah I I'd say let me make this spec update proposal and then we can we can take it from there and see if if we really really can't go around it uh yeah just for the bation I think if you have a map that say okay this transaction is touching this time I think it it will be okay for the paration just uh it would be enough cool anything else on this topic

uh ran yeah yeah apologize uh I was a little bit late so this last conversation was it about including preimages in the witness in general or specifically about this map of the dependencies between the transactions or which transaction touches a particular account yeah it was it was about adding preimages in uh relation with uh with the bit map of saying which transaction get touched by which uh but we think we don't really need it after all to be confirmed but we probably don't need

it okay but but we still preserve the the pre-images in in the witness like regardless of this map correct no we don't put the preimages in the witness uh okay so there might be some confusion because um Gabrielle has proposed uh I think it was during Kenya the Kenya Workshop that we put the preimages in the witness during the transition to somehow solve part of the pre-image distribution problem problem but uh this is uh this is something we're still thinking about but uh the I would say the so far there's no decision on adding preimages

to the witness at all because it would increase the size of the witness and there's no clear benefits so far that we have identified for sure that would require us us to do this okay so uh a little bit of context from breath side and I know this is true for arogant as well we we primarily store the the state by by the pre-image so that that the whatever the outcome of this decision is is pretty crucial to us like potentially we would need to to change our database schema to St by by the all of the accounts by by the hash

key um I understand why that would be critical but why would that really be case uh for you because currently the tree itself is completely uh hash like right it's the when we call the secure train G it's a it's a Kack of the address or the cat check of the slot number and yet during block execution you collect all the account address like the preimages and this is what you store presumably you would be doing exactly the same thing while executing a veral block so I don't think I mean of course I don't know your code base but uh I don't think that

would be a problem for you in that case yeah Fair uh uh I was more thinking about the use case of of a stat clim yeah I got mixed up you're correct here I mean yeah I'm uh I'm happy to discuss it offline as well if uh we want indeed like you said we want to make sure that's not going to be a dead end for you so yeah let's figure it out uh as soon as possible before we we make the wrong decision I don't want to presuppose the value of a having a complete pre-image store but it it seems rather appealing to have if we're going to have a a pre-image distribution at the point in

which we freeze the Merkel tree and then we had uh pre-images available via execution Witnesses it seems like the you know if and when there is a subsequent uh change to storage and we have the same pre-image issue again there'll be a fairly easy story for getting those preim they'll they'll be you know by by definition distributed by the chain plus that original pre-image distribution file so that that to me is rather appealing uh that makes sense however I mean yes you're you're right there might be a I mean there will probably be a further uh tree format change maybe in five years hopefully not

sooner uh but uh what I would say is that Witnesses are going to be deleted anyway otherwise you're just moving the data from one location on this to another other location on this so Witnesses have to be deleted at some point so I don't think uh using the witness to to do this to to do pre-image distribution is uh is a reliable way to do this uh for long-term distribution of preimages during the transition yes uh after that I'm not sure I think we would need to Simply require every client to store the preimages and to distribute them um but I don't think yeah I don't I don't

see uh how we could do it with the witness and make sure that it's there forever because like I said witnesses will be deleted just after the transition do you want to keep using snapshot based on Kack or do you want to migrate to another um kind of snapshot using stem or something like that because if we don't have the address and Slot after the transition I think it will be hard to populate uh the snapshot with the data from the witness because the witness will only have the stem so you will not have the Kat of the address or

the KCK of the slot so you will not be able to link the data from the witness to your snapshot because when you will run the evm you will try to find an account by Kack so I think we will have a problem at at this time uh yeah that's a good point uh Tanish how do you implement that like at the end of the sync how do you how do you I mean I know you're you sorry yeah because for for example for bzu in order to match that after the transition we will change the flat DB so uh the flat DB based on kak will not be used anymore and we will use directly the leaf of the tree but I wanted to

know what you will do in your client to sure uh yeah for for guess it's still an open question which is why I'm interested in what nethermind has been doing because they do have an implementation of the of the sync can you repeat the question I didn't get the question exactly uh you you know you have your snaps or your you have your veral sync with healing and everything what is the format you use for for uh for the the flat DB or the snapshot do you key it like the key format do you use the kit Shack or do you use uh the simply the the stem

value uh I'm using the stue right now no catex for work okay uh so that's basically what what Karim is saying so yeah we would need uh yeah okay there there's a bit of design space that we need to explore here yeah no I I don't have any answer right now but yes I agree this is this is something that needs to be clarified cool uh so we have two topics

left and we're running a little bit low on time time I'll just put both the topics out there and we can decide if we want to get into either of them or maybe save some for for the next call uh topics are the recent proposal from Peter around El cross validation I'll drop a link I think it was discussed on the most recent ACD I think most people here are probably already aware of it um the idea was maybe just to touch on it here a bit and see if there's any further discussion needed on on this topic or just get people's input and ideas around this idea um and then the last topic was a potential or just yeah discussion around the cost of xcode has SLX Cod size and uh this was flagged I

think by by Gom actually so do we want to get into either of these um I don't know G maybe if you have any thoughts or if we want to save this for next call uh I'd like to go with the E uh first because Dan was here and second because uh I a conversation with Peter this morning and there's a few things we need to dis like a few more things we need to explore so I would rather do the eof stuff yeah and just just to introduce it um so I discovered recently that uh I mean Mario pointed out that there are actually three things where at least eof is different than uh than Legacy code um it's to do a code hash it's to do a code

size and uh there was the xcode I'm trying to remember what he said this morning uh when you X code delegate or something like this uh for each of these things if I understand correctly you need to go it's not just getting the code hash uh Del get the um okay delegate call yeah exactly that's what Mari said so from what I understand and for those three operations you cannot only just read the code hash you also need to go and check that this is um a format sorry that this is a eof format so you need to go to the

first bite of the code check that is 0xf if I if I remember correctly and then somehow uh update the answer based on this my question like so I have two questions like first uh how do we handled the gas for this actually that's the second question because the first one uh maybe prevents us from uh asking the second question or saves us from asking the second question uh the first question would be we have this code size field and this code hash field in U in the contract excuse me in the in the header could we not directly put that value and so that we don't have to go

and read the Zer EF we could totally put a flag in I was about to suggest that because we got those two extra bytes or however many extra btes and you want to save some of them for flag Fields this is a perfect flag and the flag would be the first two bytes and that's actually EF z00 it's not just EF we want to worry about um because EF z00 marks that it's eof code and I think that um 7702 is already wanting to mark it as being delegate code so that might be another field we want want to Mark in there uh right okay so that's good but uh maybe maybe uh you could also explain

why uh why does eof have a different code size or a different code hash so why don't we just as yeah go ahead EF itself does not actually have code size code hash and code copy um one of the mandates that we've been given was that we're supposed to get rid of code introspection So within eof code you cannot go into eof code look at its bite code change its bite code expect it to behave based on it bite code contracts are opaque from within the execution of the evm so it's actually we're changing those um three EXT code uh op codes in Legacy as well as um and well EXT delegate call yeah I'll get there in in quick but the three op codes

of um EXT code copy EXT code hash and EXT code size cannot introspect into eof in order to preserve that otherwise you would just call into Legacy have the Legacy do the introspection have a return it so that's an attempt to keep the system closed so the the changes to the Legacy EXT things would be if they see an eof contract to treat it as if the contract is just the byes EF z00 and code hash code size and code copy all provide the correct answers as though the E contract is just the two bytes EF z00 um now EXT delegate call um there restriction within eof you cannot delegate call into Legacy code um and this was a decision made um before

self-destruct was was nerfed um because we wanted to make sure that we accidentally didn't accidentally bring self-destruct semantics into eof um because you could just delegate call into an external contract that would self-destruct and the self-destruct would affect the code um object that would be the eof code now be a way that you could remove it from the system so the decision There Was You Can't delegate code delegate call out to Legacy code and the generalized thing is you can only delegate call to the same generation of eof you know in 10 years and we do eof2 um that's going to be what where things are going to start from is if there's eof2 it can't delegate call the uf1 assuming we even need that in 10 years um so that's the

premise there you could still non- delegate call out to these and still get your Escape hatches but they don't affect the code object that is the eof code object so that's the rationale for the for those two changes and um so yeah the idea of having a flag that pre-calculates that and stores that in the in that first um you know Master description of it would really make things simple otherwise we would need to include in those um operations the cost of loading the first code chunk from the code from those so so we could inspect it as part of the operation those are the two realistic op options that we have for this right yeah I guess this is a very good reason to use a flag um so just to recap

if there's a flag if the flag is like the E flag is set code copy should not work sorry uh code code size and X code hash should not work neither neither does code copy that's the they work in eof mode it'll copy two byes EF z00 the size is two and the hash is whatever EF z00 is so it's it goes down a separate path so it doesn't work the typical fashion but it does work in a way to signal to say hey this is eof code versus this is an empty account okay so if I do a code hash or a code size just just to recap yes I understand could copy would work differently which which is fine because

the the gas costs are more or less uh can can be adapted basically uh but if it's just for code size and code hash then I don't need to go and read the read an extra chunk that's my that's my worry right if if we have a flag for it yeah we wouldn't have to read the chunk okay so that's good so I can also prepare an update and run it by you uh like a spec update I mean and then for code copy okay it still needs to be handled differently but just reading that flag would give us enough information that we know we need to behave differently okay we could make it cheaper for the eof because we don't have to load the chunk but I say we still charge for the first chunk anyway

just to be consistent and not special case out code copy uh the first chunk sorry in case of EF and we do a like we charge for the first chunk doing doing what sorry so if you do EXT code copy and you know you're doing eof you don't have to load the chunk um but I mean we could just keep it specified as you will still load the chunk anyway just to keep the spec simpler yeah okay that that makes sense okay cool thanks for the explanation at least I don't have any more questions cool uh then last up we just

had a PSA that we wanted to schedule another little mini breakout around gas cost updates maybe we can actually schedule that offline um but I think that was the last thing on the agenda K did you have anything on the the gas cost breakout you wanted to to add here quickly yeah so uh like I said I think a bit earlier unless I forgot uh there's there's been a significant amount of updates after the last breakout gas cost breakout we've had to the spec uh I just wanted to make sure that everybody was happy with the update that nothing was forgotten that nothing was fully specified uh so I would like

to uh bring your attention to the the fact that there's been a a PR merged last week and there's another outstanding was made by gender that I will review uh after this call I'm sharing it in fact uh right here um so it would be nice if the people interested could have a look at those two things and we could have a hopefully final uh specification call so that uh you know if there are some if there are some need for more discussion we could have a breakout call if everybody is happy with it then we don't even need to have the call but uh yeah I would suggest next week at the same time

as the Vic if uh if people are interested like we could block that time already and cancel it if it's not needed cool so yeah everyone can take a look at that and we'll coordinate offline if it uh or as synchronistically I mean see if we need another call or not awesome okay great well I think that's it for this week then unless anything last minute we can wrap there thanks everybody for joining see you soon thanks bye see you