Verkle Implementers Call #11

Transcript

all right welcome to veral implementers call number 11 I have shared the agenda in the chat this is issue 941 in the PM repo uh starting off with client team updates would anyone like to kick things off yeah I think I can go ahead so for the nimus client we have been working on the V tra library and finally uh it's been ready for the past few uh days and the testing has been completed we are Computing the

root commitment correctly and uh we from this week we have started to look into the uh integration of it into the eth1 client and we're talking with the person who was mainly developing the database layer uh so yeah we don't have any perfect estimate like uh till now uh maybe after tomorrow's call we can give an estimate like till when we are looking forward to having it fully integrated and alongside that we are also working on few optimizations and uh writing the statelessness part go next so we are we did some

improvement on the Bon native side so we can generate uh the state root of the Genesis block um more faster before I think it was 15 second and now it's less than 1 second so we still have to do some optimization but it's clearly better uh so we normally we are able to import the block 12 uh we did the modification for the gas cost uh I'm not totally sure because the guy who is working on that is sick today so it's I don't have the the final result but it seems that the last news I had he was able to import the block 12

so we we did some fix we are also working on the gas cost in order to import more block uh and still working on performance Etc so yeah we are moving forward no no huge problem for the moment yeah let me um add on on the B side where we we're we're going as well um for now we are not able to produce uh new blocks uh so so as Karen said we going to be able to follow the chain the test net uh but for blood production we'll need a little bit a bit more of the

crypto uh part ready um and uh and and uh and optimizations so that it uh we we have some uh ideas already uh of of known optimizations that are what we know we get inspired by by what people did on gu so uh so we have identified three or four uh potential optimizations to to improve speed and so this is the things we're going to do next in the in the next month on etherum GS side uh we are

working on house cleaning work basically carrying our current stuff uh reviewed and merged and we are waiting for constant in three launch so that uh we can try stateless executions on that and in the meantime we are also looking at how to incorporate the proving library to verify pre-state and postate uh yeah on the GU side um well we've uh I mean I've been working on the shadow Fork uh with per and yeah there are still some issues I mean it's a bit frustrating because there's always something

going uh going all right but um yeah like we we still made a lot of progress It's just uh it's just that we're not quite there yet um on but most of the work has been on maintaining the or more exactly updating the code base for the test net uh we had some merge issues that we discovered this morning so we need to fix them but once this is done we'll be able to to restart the test net which is quite quite important because there were some bugs that um effectively are blocking other clients from uh from sinking it so yeah we're going to fix this um so Parry said he would be able

to relaunch it this week so it's just up to to us to fix all the merge issues we we found otherwise ignasio has been nice enough to uh to work on the replay we have this replay Benchmark that was broken after a rebase so um he started tackling it but yeah it's still uh still work in progress as far as I can tell but it's it's quite useful because we want to be able to answer some questions that have been asked uh from us like what is the average uh proof size and things like this um otherwise I've done a lot of work on updating the specs so we will be discussing some of those updates uh today and I implemented IP 2935 I um also have a couple questions

regarding this that I want to to discuss here if time permits and more importantly uh we also worked on a transition like a new proposal for the transition so it's actually not the conversion but I will explain all that uh yeah later during the call and uh right for uh for this week we have a presentation on ACD uh next next Thursday so we are we're going to to tackle that we're going to try to rebase on top of the latest gu to be able to support Cancun in the future and uh right basically build everything we can to like get get as many information from the replay as soon as it's fixed and uh yeah that's pretty

much it I think I can go next so from NE M side uh I implemented the block CP that we discussed uh last uh Implement call but game pointed out some issues uh for like when we live implemented for minut but I think the current implementation works for cost except for that I was just trying to look for performance improvements in the cryptography library and on the client side while generating proofs and uh basically verifying stateless commitments so yeah that's it for Aron uh we are waiting for uh the fixes that GOM is proposing for get and

I also tried to generate some preimages uh through the plain State database in Aron it comes out to around 37 uh gigabytes so you know we had a discussion me and giom and uh Andrew from our team which uh might seem like a bit uh longer than expected uh will resume development on Aragon uh to get uh merges the fixes anyone else with

updates um I can add a quick something on the ethereum JS side so we have kind of a smaller sister repo for a u wasm typescript uh implementation of the Bol cryptography so we will be reimplementing pson hash um in typescript using the underlying uh rust compile to wasm that Kev has built so it used to be that the Ross had Pon has directly uh that library has been uh changed slightly so that's it's a bit lower level so we're going to reimplement the higher level

Pon hash implementation in typt natively yeah I've made a a few changes to the rust vericle and uh they've been upstreamed to the Basu native Library um there are couple changes that I think that uh we'd want to make like renaming pison hash to be called maybe get true key has um I noticed the geff library uses from btes I think we want to just get rid of big Indian uh sort of from the API anywhere it's a bit confusing because um in some places we use little Indian and others

we use big Indian uh and mostly just trying to get p spectors across the stack okay uh moving on to agenda item two test net relaunch Gom I think you had some thoughts you wanted to start with there um yeah maybe just uh the announcement so we're going to relaunch the test net like I mentioned during my my update um I just wanted to specify so

all the all the PRS or all the changes we we discussed last time are are in or should be in as soon as the merge issues are fixed uh there's just a couple things I wanted to mention for the for the update so uh except I can't read my what I've wrote anymore oh yeah yeah uh the gas model is the same uh except that we changed this uh so the same as the current state of uh of calinin except that we are going to not charge gas for the two and from but that's the next topic um we also uh not include the coinbase to the witness if it's zero like if the if there are no withdrawals happening or if

there and if there are no fees like if the block is empty that is really empty you don't have a an unchanging coinbase in the in the in the blog proof or in the block witness and uh yeah uh we my interpretation of EIP 2935 is uh is active and it's a bit different from the one described well the the one that is described in the spec um was created for something before veral so we had to I mean I assume Tanish also had to get a bit creative for this um in my case at at least uh there will be two blocks uh added to the witness or two locations added to the witness the first one is the location of the block you are

interested in and also the location of the block that is 256 sorry 256 blocks ahead of um of the current block and that is necessary because uh yeah I mean at least necessary in in the code base because we uh because of the way the the fork is activated um and in fact uh yeah I mean I was going to cover that later in an agenda item uh but I guess we can skip the agent item in that case um yeah so because the fork is activated by a block number sorry by a block time and no longer a block number like what is described in the in the EIP we need to

find if the block um that was uh 256 values before was uh also part of that fork and one way to find it to figure it out without having to read every single block from the from the blockchain which is not possible in stateless is to check if uh the number for that block the the hash for that block sorry is present in the contract because if it's in the contract storage then that means at that time the that block was activated and therefore uh sorry that fork was activated and therefore we are in the situation where

we should read the blog hash from the storage so um yeah I uh I think there's a link in the page uh sorry there's a link on the on the veral implementers call 11 issue it's the last link actually uh if you want to go look at the the discussion how I updated or I at least how I ask questions uh yeah G11 Yeah so basically if to access the block uh uh so with regard to whatever the index is and it does not exist itself in the tree then that is the

direct way to know whether the fork was activated at those particular blocks before or not right right so the idea is exactly if you if you find something that means the block was activated 256 uh blocks before sorry the fork was activated 256 Forks blocks before sorry and as a result you know that you're in a case where you should read the contract if not that means well in statelessness that means you have a problem but um yeah if not you you need to be stateful basically but uh you basically don't need to check for 256 because if for example at the index that you are

looking for you don't have the uh block pres the key present the data present then you already know that basically that uh at that particular index X blocks before the contract was not activated no because uh the the thing activates 256 blocks after the fork so you need to know what was the state of the block 256 blocks agoes uh so one other question I have is so uh like if so right now we planning

to enable this EIP with the veral EIP also so for the first one 256 blocks will not have uh stateless clients like if we go with this approach right uh yeah that is correct although actually the way it's implemented in my code uh is just that it will detect that the fork is not activated but the result will be zero anyway uh yeah so that's actually now come to think of it this is incorrect so yeah it will not be active for the first 250 blocks you're right so that's that's another issue yeah so can we do something thing where like uh for the first the fourth block

we add all the like last 256 block hashes and then from then we always we'll always have the last 26 block hashes from the like block itself we just have to do once on the four block that you add all the last one yeah but 256 blocks and then we can just move on as like it's already been active and we not have to wait for another BLS I would say that's a bit tacky because you have yet another situation where in some case something is enable and in another case something is not but if there's no better opt option I guess we should do that yeah so okay I guess we should um we should think that deeper um might not be active on um on kelin at first uh but

yeah we should we should fix that for sure you're right uh but on question I don't think so we'll need it anyways because we are starting from Genesis yeah but exactly it still activates it will try to read a contract that's empty um so we will say no the block the 200 my 256th ancestor is uh is missing so I cannot use the the old system so I have to read the blockchain which for a stateful client is not a problem but for a stateless clients is going to be a problem but in question and like we'll not have any scenario right where they will not have the 256 ancestor

so so on C we not have this issue where we don't have the Block in the datas right because we starting from Genesis so for every block we are reading the block has in the block hash in the state so we don't need to do this on question right but my message of checking your 256th ancestor is not going to work in this case so it will tell me um you're missing you're missing this block so you need to go the the old method basically no but that's what I'm saying like on C there is no old method because from Genesis itself everything is in state right so like we

don't have like there will never be a scenario where we'll have to switch to the old method uh I mean okay I don't really want to hug the entire convers on this uh I think we understand the problem let's sck it offline if you don't mind yeah but yeah that was it for the that was it for the test net relaunch so hopefully this week cool um so next up we have a topic on gas accounting schedule changes uh Gom I think you had some thoughts there as well also just in the interest of time maybe we want to try to get through this

one and agenda item four quickly to get to the to get to the transition disc discussion so actually in my view this is the most important one and it's I mean yeah we we can I mean they're all important to be to be honest um but my uh my question is I see V not here but D is U I'd like to revisit the the concept of of the gas cost because I think we're at a point where there's some at least on my end there's some um some confusion and uh yeah what what was basically what was the point of um of

creating for example something like fi cost or all those extra witness cost my understanding was that it was to limit the growth of the block size which makes sense but then we have things like fi cost which is charge every time the leaf is initialized so that has witness cost first so witness cost is everything that is charged for adding values to the witness so for example it's I mean it's defined it's defined in the EIP they're called W witness underscore um well there are several of them uh W Witness chunka witness uh try to remember the exact the exact

names um but they're U yeah they're called witness exactly witness uncore Branch underscore cost and witness uncore chunk uncore cost and then uh there's an extra cost for the right when you create a field cost which is the cost you charge and we we're not charging it on kelen but um it's in the spec so it should be it eventually and um and yeah it's like every time we add a new Leaf we have to charge this cost but that doesn't grow the witness so that's what I'm trying to understand like why are we uh charging this is it to limit the is it to yeah is

is the goal to limit the state growth for the for the blog producers um yeah trying to to make sense really of uh or at least re revisit because I don't think my understanding of uh of those gas costs is really clear no I see okay I'm looking at this now with this Branch cost business TR cost but it says it's only charged once per um right if address sub is not an exess sub

Char so it's only charged once yes it's um it's charged upon access absolutely but there's the field cost uh which is in EIP 4762 at least the way I understand the spec is that if um if the the leaf was zero or nonone actually it's called um like looking for the exact line um if the the additionally yeah if there was no value stored at address subkey Leaf key I.E the state held none at that position charge chunk Fill cost so this is this is the part that is confusing um

well if there was uh it's yeah for reference it's line uh 248 246 sorry 2 246

right I guess this is the cost for adding an additional sub tree right that's chunks for the cost um actually just says Lea um if there was no value stored at address sub Key Lift key so it's not about adding the sub tree it's about adding a single value let's see okay so it's adding going leave all

right so it's it's basically just the cost for like um like storing a new value right in that case uh sorry I didn't quite get that it's the cost for storing a new value exactly yeah yeah okay I see but so uh because the EIP doesn't really say the cost for s store disappears actually I was I was double cheing and I I don't see being removed so that's where I'm a b remove the following yeah gas cost gas cost e2200 s store gas cost right that's true there's that for S load gas uh right and it's

except for S load gas and S load gas uh right charge change for not change reset so okay right so that's fair no it's actually deactivated that's true uh okay so that makes sense um and then there's the whole question okay so um this is still not not great because in um that chunk edit cost means that in order to charge the the cost you need to go and read the tree and um this is this means that I mean at least in the way I've seen veral implemented in gu and and other clients

the tree gets updated at the end um so we don't really hit the tree before during evm execution and I don't see a way to implement this uh implement this chunked cost without actually needing to read the tree to see if the value exists um right um yeah but you do need to read the tree I mean whenever you have a like when you have a read for example like you do need to know anyway what the value is to to perform the evm execution um yeah that's true you need to know

what the value is but you don't need to go through the tree but yeah I guess that means the same here you only need to know whether the value is none yeah that's true okay so okay yeah you're right it might be possible to do it so I have to yeah I would have to think about it uh okay and my the second thing I wanted to talk about in this cost uh this cost thing is the I just created an EIP or uh for actually not an EIP an update to the EIP where is it um here so it's p request 8138 um and it's

about adding not charging the two and the from so this is what I mentioned about the caltin and relaunch so the the problem with this uh this approach is that we we still charge when we when we start a transaction we still charge 21,000 gas and it feels that uh I mean in the current implementation at least on top of that we need to add the witness cost but then what is the meaning of this 21,000 gas if if we have to add the witness cost on top of that my understanding uh or at least I think there should be a new interpretation of this 21,000 to says that cover that covers for adding uh the two and from

addresses to the witness and the reason for this is because well first it breaks a lot of tooling um it makes simple transactions way more uh expensive in terms of gas and I for one cannot justify this increase in cost yeah no I think I agree with that I think I think that should be part of it yeah like I mean previously we also didn't charge for that ass store so yeah I agree I think we should just say that the base cost uh in includes those like three or four um reads and writes okay excellent and uh the next question is basically the same thing for

call uh which uh is is the same thing like when you do a call yes you add the the code and that should be paid for uh especially since you remove the the 200 byte per contract code cost actually that's not the same thing but yes it's still it still makes sense um but at the same time uh you will touch you still pay a stiff upfront gas cost uh and you know to load the the account the the target account so my advice or my suggestion question would be to do exactly the same thing not include the two uh like the target of the call or sorry include them in the witness of

course but not uh not charge for it do the same thing for a call basically right um yeah I mean the difference is going to be quite small right like it's going to uh because like they the uh depends which code you're loading right the code could be somewhere in the middle it couldn't be there so it could might might not be in the same sub tree exactly right interesting y um yeah um right what's the cost of a call at the moment um I don't quite remember but it's uh yeah it's more than the witness

cost for sure okay but then I think that's fine yeah yep in that case I think um um okay um yeah I I mean I I have this uh PR that I need to complete with the call C cost and verify that everything matches and then I will share it uh with everybody to make sure that everybody agrees and if that's the case then we'll merge it good okay cool thank you uh yeah that's all for

me okay uh gam do you want to keep going with the next agenda item the account header question uh the account header question sorry I don't quite remember what we're talking about uh oh yeah yeah yeah good point yes um right right so in the spec um yeah I should look for the spec uh which one is it um okay yeah sorry wrong uh wrong window um but in the spec it says that the first 64 accounts sorry the four the first 64 Slots of an account are um

going to be in the account header group or the I don't know how to call it the header group um right this is the this is the formula that calculates it let me share my screen again um and no actually that's the right so that's the formula and basically what happened is that if it's below 64 then it is stored in the headers header um group and if not it's stored in the main store storage but here there's um the the offset is not like 64 is not subtracted to the to the storage key so that means

the first 64 uh Slots of the first of the second um of the second group or the first non-he header group is are actually unreachable and I I'm fine with that because makes things way easier to debug when you're aware of this fact I just want to know that everybody agrees and uh yeah and um this is intended basically that was the ined purposes of this of this approach so what do you mean by unreachable um right so you see that

that function get tree for storage slot here it gets the address right and it gets the the storage key which is just the slot number and this value code offset minus header storage offset that's 64 so if your storage key is in the first 64 slots it will go in the header offset so you will just add header of set which is 64 to the storage key so that's a value between 64 and 128 but if it's above so it's uh like index 64 and and up it just gets added to this value and this value uh so that means if you're for example you're the six the

65th uh slot so uh index 64 you will be at index 64 in the group that in the yeah in the the first non-he header group or the so yeah so that means the first 64 slots are unreachable in that group you're talking about the actual storage layout rather than like the account the the evm doesn't know anything about this right the evm doesn't know anything about it it's just the TR and like you could subtract um head storage offices here basically that's the question we can yes should we

that's a different question but the we can yeah interesting okay if we actually like now looking at this can this Overflow what if storage key is 2 to the 256 minus one um Can this over flow um I would have to double check in the

code but I'm pretty sure not because then uh we divide yeah right because we divide we only take the 31st uh actually when we get storage key we get the 31st bytes uh because the the last bite is uh stored somewhere else so if you you know it's this line basically um we do the math in such a way like we delay the the the cast to 256 so that we never have this problem this is how we fix it so no overflow I see I see okay

so my suggestion would be to leave it as it is just uh make sure it's documented because it is quite nice to uh to debug you know exactly you you when you look at the witness you you have a correspondence it's just that it might be confusing so that's why uh yeah it would have to be documented but just wanted to make sure there's no reason to to fix it in a way the the only drawback is that if you store um stuff in storage slots 65 66 there's like a branch in the tree that is not really it's like

50% feelable in a way um I'm sure it's that a huge problem but for like the gas cost of storing stuff in that branch is actually more expensive because you can only store half of the data that you expect to store something like that um but I don't know if this is like a big problem or not really and also if we shift everything by 64 the storage slots will be kind of unaligned corresponding to the place in the tree I don't know if that would be a problem but a benefit of how things work now is that everything

is aligned um so if you look at storage loot the storage slot number um you kind of it is kind of aligned to the 256 group in the tree um but yeah I don't have like a strong opinion just like mentioning those facts Alber uh sorry I didn't quite catch White why could it not overflow uh because it's um you only take the you see like the the address that is um highlighted on my screen MH it's a division by 256 so

you're doing 3 one bit sry one BTE arithmetic and a 32 byte uh word so you're you're fine okay got it but yeah ignasio is right that this might have a gas impact um I still think we should leave it as is but let's uh okay my suggestion is that we leave it as is right now and if uh as if as it always will uh the um the question surfaces again we can uh we can make a decision with better information because honestly it can go either way so I'm all for not changing

it cool thanks okay uh so next up the transition simplification proposal from you Gom right um yeah so actually before that I hope we still have time but I wanted to uh maybe ask the uh res people if they because we didn't get to we didn't give them any Voice last time um are you aware of the of how the proposed overlay transition works and do you have any uh any comments on

that um we are aware uh initially we thought that reads would also transition into the veral tree which was like something we discussed just internally and we had a lot of issues with because of the way our node is designed it would be a m but I understand after uh we talked that that is no longer something uh that is part of the overlay uh transition method right like when you when you read things from the Merle Patricia tree it isn't automatically transitioned to the verle tree it's only like uh the fixed increment using the iterator and then rights that go into the work verle tree yeah exactly yeah uh

after that it seems a lot simpler um so I don't actually think we have any issues with the current uh proposal yeah it's it seems doable uh from a first Clans I've been reading some implementations like I've been scamming over GI to try and and answer some of the questions I had and it's it seems pretty reasonable from what I've seen cool well that's uh good to know so yeah if if if you have any uh realization later uh yeah we we'd love

to to hear from that um I think ER I mean I talked to them as well but some that do you have any comment as well or you know are we are we still at the point when uh we discussed last time uh no I don't have any specific comments Okay cool so then I can uh share my screen again it's uh screen sharing heavy today um and I would like to uh propose a simplification for uh for this overlay transition or at least

not the transition itself but how we approach the the delivering of of veral trees in um in main net and this is something I did some time ago to explain to my colleagues how the veral transition Works uh sorry the overlay transition works so you have the uh you have the the blockchain here you have the state of the MPT and you have the veral tree and so uh the MPT is frozen so it Remains the Same um as things as time progresses and the veral more and more things get written into it and at the blog finalization um the internal data of the MPT gets deleted because you no longer need it really except for sync but other

other methods can be used and then going back to the going on to the next slide so that's the I'm just copy uh copying the the last state of the previous slide so the the data has been deleted you have an iterator that goes over the the leaves of the of the MPT and just starts copying them so at the first block a gets copied and then the second Block B gets copied and so on and so on um and well it goes on until the whole iterator has been um um as like the the whole Le all the leaves have been covered sweeped by the

erator and then you just delete the data and you have veral Tre days converted now the proposal the new proposal um because this whole conversion is risky and complex and uh and uh well difficult to to make work as I as I discovered um it's uh the suggestion would be to have a first Fork where we just implement the part on the first slide so we just start with a fresh tree but we keep the the MPT in the background and that part where the internal data is um is deleted Still Remains so once the once

the fork block has finalized you can delete the internal data of the sorry the internal nodes of the of of the of the Merle Patricia tree but you remain indefinitely in that uh in that intermediate space where you have two trees um so why do I suggest this well there are several reasons um one of them so I I summarize well there's there's some reasons not to do it first uh that means you cannot really have proofs in blocks so that means we delay stat statelessness so that's clearly a a minus or at least more exactly we delay in protocol statelessness you could still work on having uh stateless

clients that uh get their proofs somewhere else and it uh annihilates um all those fancy uh synchronization methods that especially tennish worked on so that's not great but at the same time these are um the parts of veral that are going to take time to implement and are going to delay veral um and meanwhile while all we while we get we try to get everything right uh the state the MPT keeps growing so that's why um I propose to just do the first part and focus on that uh the advantage is

that all the clients more or less have the code for that I mean they would need to create that same layer that currently exists in gu where you have the ability to read first from the veral tree and then from the from the MPT so there's still some uh codee to to be added but the the snap sync will still work uh you would need to develop um simply a update snap sying to also handle vertical proof so it's not like we're not doing any proof but um it's still simpler um and you the the biggest Advantage I see is that at least we stop the growth of the MPT so while we figure

all the fine details of the overlay transition or any other transition because then maybe the uh State expiry becomes the the best method after all um but yeah while this happens uh we can uh we stop the the growth of the MPT which is the biggest problem and then um yeah we can uh we can already delete some of the data Maybe the sync of the MPT can be left to EIP 44s which is also an IP asking for attention so maybe it's not a bad idea to do it right after uh after that first veral uh that first veral Fork um and then we can still work on um

out of protocol statelessness oh and one thing um I wanted to ask uh jumping back on that uh on that gas question if we do not create a witness um I guess there's no need to create uh I mean U I'd love to hear if I'm wrong but my understanding is that if we uh if we don't add the witnesses immediately we don't need the gas cost right off the bat uh to change the gas cost so that would provide that would give more support for veral because some feedback that has been given given to me um was that yeah changing the gas cost

is what's going to provide the biggest push back so at least we get some of the benefits without having the uh we we get some of the benefits of uh of statelessness without having to justify every single gas increase and uh the other Advantage is because we don't put the proofs in blocks we don't have to bother the the consensus layer to to forward those those block proofs for us uh so yeah that's basically the The Proposal in the in the issue like the PM issue uh there's there's a link to the to the proposal draft that I have here um let me share it again it's uh yeah it's

right here exactly but you should have access to it so you can comment um and uh yeah I see some questions uh oh it's from Han how do does this new overlay method give an immediate use case to e44 um well EIP 44s is is about deleting the history and presumably recovering it um so that could actually be a portal Network thing that could be I'm saying four4 but um let's say it opens uh some interest towards those those issues those eips and those concept that propos to deliver historical State over

different channels than than the usual sync that's what I meant um but yeah get getting back to the getting back to the uh EIP so we have uh like there's a simple description of it so you can uh you can read it and you can everybody should be able to comment so yeah please do that and uh I'm going to yeah I think that's it so if you have questions I'm happy to answer them um but yeah that's pretty much everything I wanted to say I think there's a question from Oliver in the chat too yeah um how will this affect l2s that reord state proofs from L1 um I mean it's basically the same uh

thing as um as anything that would get uh that would need get Prov during the transition because even if we did the the overlay conversion uh and you know for a limited amount of time like let's say it lasts two weeks or three weeks or whatever during those three weeks you need to be able to provide two proofs so the idea was would be that you yeah you provide two sets of proofs um but only if you need to uh to access historical state if you don't then only the vertical proof is uh is enough

any other thoughts on this proposal are people generally in favor seems like perhaps any concerns other cons yep Tanish uh but then how long do we wait to actually like enable the gas CA then enable the proves and then we do the transition yeah that is the question um probably a year probably two years depends we're going to have to to fight to put that in but um the the the thing is if we don't get in right now I would say it's going to get much harder to

handle the conversion so that's why I would say um it doesn't really matter in this respect of course it does matter because you still need to be able to deliver the full product um but yeah because of this need uh right because one thing I didn't uh specify is that because this proposed change is much simpler we could have other eips activated at the same time namely everything that is in Prague so we could uh we could shoot for Prague um yes that would delay prag by maybe six month but at least um it would be it would be there and the state the

MPT state would stop growing so uh yeah I agree it's hand wavy but what I expect is when um you know a lot of core developers I.E the guest team are going to look closer at the at the whole conversion there's going to be a lot of push back that's going to delay everything so I would rather have this conversation after the mpts started growing that's the that's really the the core idea behind this this proposal uh so and like would it be too bad if we added like okay I understand the conversion part is bad because that will take time testing will take time it will delay by a lot but can we not just add gas cost and Witnesses because I

think uh like adding gas cost and Witnesses kind of then provides to us with almost all the benefits of shapeless clients because yeah right now without that like without Witnesses we don't get I think any benefits of status n right now we'll have to like query like third party for proofs this way you can just download the mptn I'm assuming that without internal nodes and without all the other things just the state would be a bit smaller so if someone just downloads the MPD and they have the uh Witnesses in the Blog then they can act as a stess line um so I have to disagree on a couple points but overall I agree that

yes it would be a good idea I just think it's also going to make things uh a bit more like more complicated and uh potentially uh cause uh cause this proposal to be pushed back to the next fork and then the next fork and then the next Fork um but could we could we add the gas cost sure could we as add the the witnesses I guess um I'm uh yeah like I said I think it's going to to increase the proposal where there was something you said I disagree down I'm trying to remember but it was basically your uh you said you have to get proofs from a uh from a third party I don't quite understand that part

because you would just need to uh I mean if you need proofs yeah okay you would get them from indeed from uh from some kind of relayer but that's what you would do in a in a stateless uh context as well so yeah I'm not sure I understand that point so like what I'm trying to say is like right now in if you add Witnesses the uh any client will just receive a block and then they can verify the block with the data that we have already provided inside the block uh if we don't add Witnesses then the client would have to query some other node or a third party service to get the proofs and using those proof then the client will be able to verify the

block right but currently the blocks are not sorry the proofs are not um are not um sorry I'm looking for my word the proofs are not part of the block right they're just writing along there's not they're not hashed in so they could be uh it's pretty much the same problem um unless I miss your point okay but we still receiving the proof with the blocks right so right okay I think it's just a matter of just one other step but I think I'll prefer having like if if it does not delay uh

work by too much because if we don't add proofs then we'll have to like work on the healing part of Bal sync if we add proofs we can like spend less time on working on the healing part so that can be one tradeoff but yeah like if if this like gas cost and Witnesses d this by a lot then probably we can not do that in one folk I mean yeah you you rais a good point oh sorry go ahead D yeah I mean I have a couple of comments on this I think like the first one is I feel like it's very unlikely to uh to have to that people will agree to a fork that leaves it in a in in

immediate state that has to be fixed in the future um and the second is that um I see a problem yeah like I I don't know I don't really know if it's worth it like saying that like we would delay because like I mean well it is like basically the full V tree stuff has to be implemented so I'm not sure if 6 months is even actually it might even be more for Electra but also like if it's such a long delay uh is that trade of worth it because that also delays the full verer transition implementation itself again so I I kind of don't see it as being the being worthy pushing for this well just

to answer uh some of the points uh yes it will have a huge impact because the the con the discussion about the conversion is what's going to take most of the time uh I mean I can already tell this is exactly what's what I'm spending uh my time doing when I when I mentioned that to the guest team um yeah it's true that we we most of it would be there um but the one thing and that's that's what I was going to answer Tanish actually um if you enable like sync is the other big question um not putting the proofs in the blocks would guarantee that no one tries to to solve s uh right off the bat but more exactly it's okay if people

want to get S to work uh is just delaying the fork to figure out some very smart kind of sync when snap sync already Works basically right but those things still need s right like the new tree that you creating also needs to be be able to be Syed yes right so s c still has to be figured out but so it's just about adapting the ex exist exting snap sync to return veral proofs it's not about reconstructing the tree and stateless executing it because that is going to set I mean Tanish has already I believe

I believe that we had this discussion um like one and a half years ago or so with a lot of people from the guest team where they were very concerned about snaping working with v trees yeah right they were they were concerned about it yeah yeah but like the problem being that in Vero trees all the accounts are spread evenly across the whole tree and so you would get a lot more dirty trees and potentially never finish something um was it the argument I'm trying to remember okay I can we're we're over time I I can uh ping them for

that and and get back to it uh get get back to you on that on the on the channel uh yeah uh I just want to say that skipping transition seems like skipping few steps and it probably would be best to be included inside the vle if he keep that transition and leave like two branches that ask the question how the snap SC is going to work how much data is going to be bigger and how basically are when are we going to do

cleanup so what I would like to say is it it would be cleaner and simpler for the long run to do Transition when the verle happens yeah but that's actually just uh changing the order of something because you need to figure that out no matter what so yeah that's I don't think that's that's a good argument because whether whether you do it before during for before the first fork or after the first Fork you will have to figure the transition out so yeah the problem the Crux of the argument is the state keeps growing and we have to stop that yeah but your argument of not

finding solution before implementing something it's not the great the greatest there is there is there are solutions sorry to uh there are solutions they just need to be uh yeah they need to be implemented basically yeah of course but your solution basically to to not do Transition I me that or just delay it in this sense um sorry I miss that I didn't quit understand basically what you're proposing is to the delay transition but if we already have solution that we can Implement and basically work on it should be best p possible to do it right away with work transition because if you

delay that for months years it will basically increas the like likelihood that somebody's going to to do something bad in that transition time while if you have transition for two weeks it becomes a lot easier time frame is a lot smaller and potential problem can be a lot less yeah I agree but that's precisely why stopping the growth of the state matters because then we we make sure the transition is not longer than two weeks even if these three or four weeks one month it's not comparable with year like six months do you have do you

have numbers on state growth like is is this like is this your intuition right now now or do we have hard numbers that say right now it's possible and like in one year it isn't um right it's not like a clear-cut thing but currently um so my my numbers date from uh from middle of last year but the estimate like just continuing extrapolating would be the state growth uh was going to be 1 billion leaves middle of 2024 that's not relevant so like what I'm asking is how many % per year yeah so 10% per year 20% per year that's uh So currently it's 800 so that would be

uh 25% yeah 25% per year yeah okay so one year extra gives us 25% extra state right so I mean I think like that doesn't that doesn't sound like this makes an argument that that's a super urgent just stopping it I mean that's yeah if it takes two years like some people are claiming to get everything right uh yeah it's going to start having an impact because that's 50% but right but also this this EIP will also delay it sure like okay so then it's three weeks instead of two but in order to like I think you will not

make a convincing argument on ACD say telling everyone hey let's do this uh we will be in this weird intermediate state after this hard for but we really need to urgently do this I don't see that argument being very strong right now if you see what I mean like it's just like like dealing with an extra 50% does feel possible like it doesn't feel like oh that's suddenly going to make it impossible yes like I agree that it's getting harder and harder so that's an argument of doing full veral like earlier but it doesn't feel like an argument that we need to like pull the

emergency break which is kind of what this proposal feels like and I would additionally say that work priority so we should have some timeline in year and a half maybe to to include it so it's to delay y yeah I think it would also be hard to just like I think like unless we have the complete story about veral including transition and everything figured out it will be hard to convince anyone of like starting to do some partial transition to it right so there is the like I insist we do have a full vision of the

transition we're just offering to split it into yeah right cutre just a little argument here I mean one thing that it blocks us also from doing is actually um changing anything about how we actually do our hashing and so on like the discussion that we had oh how do we actually work with all of these 64 bits do we actually shift make everything align do we actually want to split our tree into multiple kind of domains I think we had a discussion with ignasio last year that maybe we want to sort of defend against these attacks where somebody makes a popular attack deep down the tree doing a lot of stuff I mean we um it sort of would H would

basically Force us to make certain decisions that we have already made but it would basically make it n impossible to actually um change certain decisions that we have made for the threee layout and that's another Coast actually that we should actually consider that right now we could basically say oh we actually do minor changes to these kind of things relatively cheaply and we will be able to do that later okay well I think since we're over um if no one's opposed maybe we can continue

this on the next call and offline gam what do you think about that yeah absolutely thank you for feedback uh I'll keep thinking about it and uh yeah um we we let's talk about it on the on the next call or not if if it doesn't make sense after all thanks yeah we can keep the conversation going offline as well of course okay awesome uh well yeah thank you everyone and thanks for staying a little bit over uh we will see you next time thanks bye thanks everyone bye bye bye