Verkle Implementers Call #8

Transcript

okay welcome everybody to veral implementers call number eight starting off today with a round of client team updates then we will touch on the relaunch of the Calin test net we have a proposal for a new performance optimization from Gom and ignasio I believe uh then assuming we have time we will touch on the issue of around the block has op code that hoger and others have recently been discussing and lastly uh touching on the veral proof verification pre pre-compile some uh potential new features to that

uh EIP that GOM uh created a few weeks ago okay uh starting off with client team updates Gom can I uh you want to start off there uh sure no real update I mean yeah we relaunched the caltin and test net so we're going to talk about this later and apart from that uh yeah we we've been identifying some bugs like gu has uh some bug with debug Trace transaction so we're aware of that we're also looking at a potential bug in displaying uh like in U in the proof uh in the so in the witness where the where the code uh Leaf number would be incorrect

um but yeah that might be a Dora problem so we just found out today and otherwise I think that's pretty much it if Ino has some extra things like go ahead no no I think that's fine anybody else would like to give an update yeah I can give an update on ethereum JavaScript so during uh def connect in Istanbul we were able to

begin syncing uh the the old consonant with the help of a gender who done most of the hard hard work on that uh we we are not uh building uh veral State locally but we're stateless executing blocks and then verifying the resulting postate with the the postate included in the blocks uh were so we're troubleshooting the the blocks that have proven to be problematic we've updated to cust and number two over the weekend I think on Sunday so yeah we're just going to go block by block and see wherever the post State doesn't match what we're getting

locally and make the appropriate fixes yeah uh sorry yeah just a quick uh quick like remark for everybody who would be interested like who's trying to join the test net so there's no guarantee like we're still discovering if there are problems with the test net so if you spot any problem uh write us because it could definitely be our fault and another thing I wanted to add is uh you could also try to join a test net first by executing blocks but you know just verifying the state route and not verifying the the gas and then only uh only verify the gas consumption afterwards so do it in several steps so

that we can identify bugs you know one by one instead of having like 15 different possible sources for for bugs about the the the gas I know you mentioned that when we were in uh Istanbul but since we're verifying the for example the the postate balances then surely that's affected by gas use because I mean one of the accounts is the one paying for the gas and therefore the the if we don't have proper gas consumption the balance isn't going to match good point yeah I forgot about this so yeah forget about that but still um yeah if you have problems like if you if there's a a bug let us know because we we could be responsible maybe maybe what guest does is

incorrect oh yeah good to know thanks y just what chime in here and that was one of the issues that uh we sort of figured out on ethereum JS stateless sying that our gas schedule was not correct and once basically we got some part of it right in an incremental way basically we were able to execute few of the blocks on loar uh basically I also refreshed the loar branch and also figured out a bug around transition so now on curtois lordstar and Lighthouse

play well for the uh for the electr transition and yeah so that has also been tested out uh so plus one for kosis as well uh sorry uh yeah question when you say you resolve the bug at the transition is that Genesis time transition or post Genesis transition so it's not transition on the eln it's transition on the CL Fork transition from uh from capella to Electra so State upgrade of Lota was not matching with that of Lighthouse so uh there was a bug there and that was

crunched out but did you test both cases like you know Genesis and um anywhere later like at a nonzero epoch yeah so transition we I tested at Epoch one with kosis for Genesis kosis does not has a Genesis uh State generator yet for the Electra so when that will be uh that will be sort of completed then I can test it with that too okay I can share on Vis side we are still trying to implement V Tre into

Bezos so we are moving forward uh currently we are trying to import the first block of the Genesis to verify the state root uh no we have some issue with the commitment uh so we have an State rout Gom shared last week a DOT generating from guest to help us checking the tree structure and the different commitment so it helped to fix some issues but we are still some some problem so we are we are working on that uh we are also some performance issues but we have some ideas to to make it faster so so I'm not really um not be really a big deal uh we can we can fix

some issues quickly without a lot of modification so we are also working on that and uh so for the next step regarding bz I think it will be to to pass the first block to have a valid State rout when we'll have this valid State root we'll be able to try to join the test net uh when I'm saying joining test just to import the different block to see if we can match all of the state frot for the Block in the test net and after when that will be okay we'll also have to work on pool generation and validation but we are for the moment not really uh on this on this topic um yes regarding integration to Bonsai I think for the

moment it's uh it's working well we don't have to reflector a lot of things so so it's really good news uh I'm just starting a small refractor of the code to help uh um to simplify the integration uh and maybe in the future to use directly the leaf of the V tree as a flat DP so just some ideas like that we are trying to implement it's all for me uh yeah we can go next so on NE mind side I don't have any significant update

like still like the last test net and this test net we figured out that there was some bugs in gas calculation just phasing some issues and yeah that's it okay if no other updates I would like to uh make one last update from arone so I uh am starting to work on work call uh trying to implement that into Aragon's very early stages uh hopefully I'll have something concrete

by the next meeting nice uh one thing I wanted to add so I don't see him in the list but uh Ben enton from uh from tiku just wrote me at the start of the talk of the call that um they decided they were going to work on on veral so we should have uh we should have something by uh he said within two weeks uh should uh they should have something so then we would have three CLS which would be nice very nice and thank you sth for joining some a gun that's exciting to hear as

well cool anybody else I think we've covered everybody okay if not we can move on uh next up just a few quick notes on the relaunch of kelin which we've already already covered uh and thanks to the Ops Team for putting this all together a couple notes the Legacy name of cenin test net has been dropped in favor of verl ddet DX and verl dg- DEET in this case it's a veral d Gen 2 this means the Genesis state is veral

there was no straight there was no uh State transition from Merkel to veral in the near future the goal will be to deploy a test net with a Merkel Genesis and then do the conversion over to verl uh one last note this current test net is still built on top of chappella so in order to sync for anyone that uh would like to sync in the future you have to make sure that uh dankun related code is is just not being triggered here uh anything I forgot to mention there Gom or anyone else uh right I there was something I wanted to add but I just don't remember uh I think you said veral gen defet two like you said veral Gen 2 it's actually

veral gen defet to but keltin and test net like the old address still works and in fact we'll try to keep it going like as we update test Nets we will um we will keep the keltin and name to follow the the latest uh but yeah like if uh if you want to Target a specific test net obviously use the the canonical address but kelen will uh yeah we'll be we'll give you an in an indication of what the latest one is um one thing I wanted to add is that we currently have a uh is that the right one yeah um so we have this landing page we have an Explorer actually a a regular block explorer that

is currently not working very well but we started we started having uh having this data I'm not sure why uh G like Google me doesn't update uh but yeah if you click if you click on Explorer here it should show you the the list of uh of like of blocks and transaction but we're currently stock at 3,000 um and not all the transactions are included so it's still work in progress but we're we're getting there so that's quite excited thing because we will be able to uh to help debug uh much more easily like if we can get the the transactions and content that that's going to be helpful but yeah so that's

early but if you are thinking at the beginning it's actually usable if you're if you find your problem much later like after block 3000 you're going to have a it's not going to help you just yet but hopefully we we can get it oh yeah that was it cool thank you moving on then uh D I believe you wanted to discuss your new proposal for the uh performance optimization for the conversion right um give me a minute too many windows um I don't see it uh

ex um oh right I'm not looking right okay so here we go so yeah it's it's a proposal um can you guys see my screen okay yeah we can yeah excellent so yeah it's it's a bit of an optimization uh whose purpose or is to is to increase the the speed of the transition and it's done by noticing that there are two special cases that we could optimize so we could change the structure of the tree a little bit to optimize the the computation Time by reducing the amount of uh of computation that is

needed so just as a quick reminder you this is the the structure of the veral tree you have the the uh like the root Branch node and you have a series of other Branch nodes and then you get into the extension node and the extension node has the first uh the first value is one then it's the encoding of the stem and then you you've got two serialized subtree root nodes C1 and C2 and for example in the case of an EA of which there are many in the state you always have uh version zero right now so it's not always uh it's not maybe the version will will change in the future but currently it's always zero and at the time of the transition it will always be zero um you you always

have the balance and the balance is uh also uh it's 32 B 32bit little Indian number but um you will never use those 32 bits because there's more uh the whole uh Market sorry the the whole um issue of issu issuance of of ethereum does not fit in 32 bits it I mean it does fit it's definitely not even close to filling 32 bits sorry 32 bytes um the NS itself is uh a 64bit number so it's also going going to fit in 253 bits and then the code cat Shack yes unfortunately does not fit in 253 bits it's it's a 32 it's a 32 byte value uh

but we know what it is it's well known like the empty the empty code and the code size is always zero and then everything else uh is empty so that gives an opportunity for uh for optimizing uh this approach and what I would propose is when we detect uh that this is an EA um we would use instead the following structure so we would still have an extension node but no value node we would set we would set C1 and C2 to zero we would change the the number the marker from one one to three um and the reason why we don't use two is because two is used somewhere

else uh yeah I can't remember it right now but uh it's definitely used somewhere else and um and so we would put the balance um in the like inside the polinomial at the next degree at the at the next uh uh available value available location sorry and same thing with the nons and then we would set zero for another use case that I'm going to talk about next but what you have to notice is that in the general case because the value is potentially 32 bytes sorry 32 bits again you it doesn't fit uh inside a single field element so you have to break it into two but in this case you know that it fits in 253

bits because the NS is once again 64 bits maximum and the balance itself well technically it could go all the way to 32 bytes so 256 bits but um yeah it's definitely not going to happen like there's more than a 100 orders of magnitude more um more um room for growth before we we hit this uh this use case so in all likelihood uh it will never uh it will never fill uh more than 253 bits and as a result it could fit into a single field element so we would save on the evaluation of uh twice as many values because here we would have

to break all those values into two uh two field elements and then evaluate as many um polinomial U value like evaluate the polinomial as uh at as many location as uh as as you find whereas here it's only two extra locations and then you don't have to evaluate any anything below the extension Noe so you save quite a bit on the amount of evaluation and as a result it should make things faster um there's also another case that I believe although I haven't confirmed um is is still quite uh quite likely it's the case of a single slot so the

the typical Cas is when you have an erc20 contract and they decide to store the the values into a into a hash table and a solidity map and what this is this is a terrible uh approach for veral because you have all your gas model is based on groups and and grouping of consecutive values so you find very often values that are um in like alone in their own group and this is already something we saw we see on the test net so this is why I believe it's going to be uh it's going to be likely although I haven't seen that with a real real payload but so what you would do uh in that case is uh use the marker four

instead of three or or one and you would still Set uh C1 and C2 to zero balance and NS would also be set to zero and then the next values will be set to the lower uh 16 bytes of uh of um of the of the slot value and then the next uh 16 bytes of the slot values so you still have two evaluations here but you're still but you're saving on one extra evaluation because you don't have to evaluate C1 or C2 and serialize them before you evaluate this this slot so uh this one I'm less sure that it would be uh it would be positive but um but yeah I think I think if we do this and if

there's buying of course I don't want to decide this on my own um I think it would make sense to to try that uh we don't have to do it now I was not planning to work on it this year but I think it would uh it would save some some time during the conversion yeah goti um just a quick remark I mean I'm not sure about the the later um optimization but if you go back to um the case with the version three can I go back on slide um there is one thing here that makes me a bit um cautious of this optimization or something to keep in mind um I mean it costs a lot of extra additional complexity which is of course a downside um and on the but I'm not sure how big the upside really is um

because if you have a um um Leaf note that is can you go back one more slide even if you have a leaf and well basically the leaf note of um below below the extension of this form then actually Computing the um Pon hash um for this special case is in is already much faster than um the general case the reason being that um in order to evaluate the pon hash you would want to pre-compute I mean you have your fixed Pon basis and you will actually do um compute your P hash by using pre-computed values and one of the ideas when we did this kind of thing is that

the um number of pre-computed values because of the presence of the extension does um we already have much denser precomputed values for the first four or five entries because the because of the extension nodes so something that is already contained in the only few first few um very all but the first few of the value are zero um can already be made much faster by making just appropriately sh shaped size of the precomputation table for the pon hashing so you don't gain as much as you would do if you were so there's basically some other way of doing this optimization that does not add as much complexity this one is

probably helps you more but on the um well complexity versus how much you gain tradeoff um it's probably not as good as as um without taking this into account okay uh yeah I mean that's that's possible I still uh I mean I'm still planning on gaining um like once again this is just for the conversion right I agree it's a bit more complex but if we save like let's say even 1% per uh of the time per uh per eof and we have like millions of eof that's going to have an impact um but okay fair fair enough can uh yeah I I could try to implement that and uh and see how much

of a gain there really is in asio yeah I have a question when when you say this proposal is for the conversion are you're thinking about only applying these rules for the converted state or is this like a general thing that will continue to be use for like new eoa addresses after B trees are fully like migrated because this is actually in theory optimizing every case of EAS not not really the state transition yeah so uh what I meant was that it would have a noticeable impact it should have a noticeable impact during the conversion then it doesn't

really matter as much but if it works I mean we would have to support this structure forever so might not why not as uh why not use it as well in the in the future yeah okay uh I have another question regarding the the the slot single slot single storage slot case if you want to scroll down so I I think that here are we missing like which index is the corresponding storage slot in this this if no because here we are only going the value really which which that's a good point yeah that's missing so that might be actually an extra evaluation and kind

of completely uh yeah then it would not make any sense to use that that thing although the index is only a single bite so you could actually stuff it somewhere in V v2n or v2n plus one yeah so we could save it we could still rescue the uh yeah the feasibility or the the the advantage of doing this um this way but yeah I mean I'm not really a believer of this one I just want to try it and see if it works but yeah I wouldn't be surprised if it brought nothing the single account thing has has also the problem that um it introduces like because you might there might be another value written um to

that same uh tree and then you would uh you would have to make a proof for the transition I don't know right now but I feel like that could be more complex and that would be quite annoying complexity right that's a good point um so um there are some rules like the way the the yeah the way the spec is uh drafted it says like there's there's a series of rules and if this rule change then you have to fall back to the old uh to the old concept so I don't know if it would actually um cause a problem for the for the proof because you would have a proof

of absence for any child of C1 2 and then uh you would update this to be zero so okay technically you would update this to B one uh like exactly like we do deletions in in leave values and then we would have some extra children so yeah that's a bit of a corner case that's not really uh nice um yeah so well all of these things just add up that's just something to remember here y Absolut um another thing to consider on the whole proposal is um okay so when vitalic uh designed it the idea was that um that we design the whole thing as a

universal um 32 BYT uh key2 value table um so I guess like we also have to care be careful if we're breaking that abstraction like his whole point was like if we ever need to do this again uh we should try to make it easier and basically we could keep the um keep the if for if for example we could keep the keys and values then the transition um would not leak outside um the pure uh commitment and storage code uh when not leak what what would

leak outside you mean um like the the values the keys and values would not leak outside the no the I'm saying like the the whole thing was was designed as an abstract key Value Store MH yeah and we want to yeah I guess I guess like yeah I was wondering if this if this breaks it but yeah probably it doesn't actually break it okay that this objection might not uh might not be that important so one thing that indeed vitalic suggested and is missing from this model but it can be added uh was that we should also put the pre-image at this level so that if we need to do

another conversion in the future we already have the preimage um that's uh yeah that's that's doable it's just missing from uh from this picture right um one extra thing to mention is that uh doing this kind of change should also have a little impact in the proof generation in the witness generation because now in all the cases for leaf nodes we are assuming that the extension marker is one I think this can be easily fixed with by a new extension status present one for extension marker one and other for three and another for four so I

think it shouldn't be that bad but but um yeah like today we don't have like all these separate cases for Lift noes so it would add a bit of extra complexity in the witness generation too and also one last thing I think this extension marker for we can simply remove this C1 C2 balance and non being zero because like four already setups and new format so we can move I mean there's all these things aren't really adding adding anything um yeah so the the reasoning for that

but I agree it's not very strong is that um if you want to do like Express this as constraints you could just confirm that you know this First Column is four and then if it's four then the other two are zero but it's true that the column being four is already uh is already enough of a constraint um so that was the reasoning but yeah I agree it's not very uh it's not very thought through it's just just yeah an [Music] intuition uh Kim you had a question it was just regarding the the size of the storage do you have some number how much would be the difference

regarding if we are saving the empty AR empty s root and if we are not saving uh no I do not have numbers so far I'm just expressing the idea because it's going to be quite a lot of work before I uh I can even get numbers and benchmarks um so I'm just trying to get some early feedback to see if it's worth uh you know spending spending a months on this or not because I think it would be another advantage to do that to to save some space uh right the transition yeah right but uh that's really not uh I mean this is something you could get anyway if you uh you know if you just detect that pattern at the moment you've write

it to your database and uh even if we don't do this this or this structure this tree structure this is what guest would do for example so just realize oh okay I'm actually storing an account here so I will not bother storing the the empt code hash for example uh so this is an optimiz this is a database level optimization that is definitely very uh interesting but doesn't need to affect the the structure of the tree proper yeah t yeah if we just think about the transition like while transition we are only doing like a batch of leaves for one block right so like over overall I

understand that this could result into huge difference in performance but I like I feel that this will not result not give us a lot of performance Improvement when you just think about like a small batch of leaves like the amount of leaves you want to convert for one block and like aggregated it would be it would make a difference but yeah like uh it won't make much of a difference for one particular slot of transition well I mean generally we should be thinking in relative improvements not in absolute improvements right like I mean when you set oh maybe this is only 1% Improvement I was like well I'm pretty sure we have we can still find bigger improvements elsewhere

that don't introduce this amount of complexity yeah um I mean understood if you if you claim those 1% I would be like well I mean that really doesn't seem worth it okay um okay fine then uh I mean I still think it's worth trying because yeah it's not going to work for sure if you have if if in your batch you have a huge uh contract like crypto Kitty or guas token or whatever um clearly your batch will be uh will find itself in the worst case but if you have a series of smaller accounts I'm I'm sure it's going to to have a big impact

so um I guess ultimately now we need to try it um I understand that it uh yeah okay I understand there's uh potentially some um some uh some cases or maybe a majority of cases that would completely annihilate the point of doing this uh but okay I guess at this point now it it needs to be tried and see if um if it works or not how do you even get your 1% number from or why even in the best case um how do you where I mean assume that every

contract actually has this form um how would you what's basically your estimate even in the best case what the how much this actually would give I I have no estimate I'm just I just say 1% uh like that I say if it's if it's 1% I I still think it's worth it if it's uh if it's less than that definitely not if it's more than that uh yeah I mean I would say why why why do you think 1% is worth it uh because it's noise to me because it's noticeable so you're saying if it's going to take us like 100 hours to transition and that makes it 99 instead that would be an

important Improvement to prioritize it's not going to take us 100 hours to uh to transition it's going to take us way more than that so yeah but even even then like relative like the relative thing matters I don't like I mean do you not think like if like it would be worth more like spending 10 more days on optimizing like that seems much likely that it gets more than 1% I like I don't get it okay but do you have any uh any other suggestion to optimize because we right now we're scraping as far as I I mean as far as I can tell we're scraping the bottom of the barrel here so if you have uh if you have any ideas do share them but yeah I think 1% of uh what we estimate to be

700 hours so that would be seven hours that's noticeable um would be uh sorry uh yeah seven hours I mean it would be worth it if it didn't create any extra complexity like but this creates extra complexity that leaks that's not just like inside the code but that's actually part of the specification like that seems like a bad trade-off to me I mean you can test it it might be more than 1% sure like if it's 10% then then it's something different but right at 1% I would give it a very clear n okay understood caros yeah sorry I

I I ignore a bit why we have this kind of index at the beginning uh aside from having one but how worth it it is to to include this in the sense from the ckvm perspective and I'm not sure from the IPA 1 but looks a bit weird also so if we have different cases for that we either need to have padding for all of the possible cases and we need to check the worst one always uh and for the IPI perspective you still should do the same exact operations everywhere because otherwise you need a different Pro key and verifier key to commit to to your proves so I'm not

sure whether is is like is is it worth it to have this prefix multiple cases for for any reason or anyone can explain okay I mean yeah I think that goes down to the to the same thing like if it's uh if the if okay let's say 1% is not enough but let's say if we get 10% then clearly it's worth it um I mean zkm is one thing but it's uh right now we're talking about user actual user experience for ual users um so I mean clearly I'm not working on the zvm that's something I'm quite happy to pay if the user is uh uh

is is willing to do this uh yeah then C yeah I mean um I would also be careful with that like 10% is clearly worth it like I think like you we have to remember that the transition is a one-time thing so like overly optimizing for that doesn't seem worth it I would say like if it's 10% of the like performance in actual operation that would be a more like a better argument all right uh yeah okay I guess do not now the question is uh yeah go te well I mean to reiterate what I just said before I mean like what Al what tank

said I mean there is probably better optimization targets for the actual transition like as as case in point would be optimize your MSM um computation for the special cases that appear That's well that will give you almost PR I mean some back of the envelope calculation suggest that it will give you almost everything that this proposal gives you at the cost of basically not have needing to change anything in the specs um well what this however would um probably help you with is actually um that your Witnesses are a bit EAS easier to generate because essentially the depth of your tree is more

shallow so I mean this is not really I mean if you do this then I think targeting this for the transition is probably not the right target it's it may be interesting for the witness generation which is more for the uh operational thing that comes later and not for the not for the transition and it potentially Sav one uh one commitment for these R methods right that right so that could be actually quite substantial okay uh yeah okay thank you I think I mean I would like to move on because I don't want to hug the the the whole call for this there are still a

few things on the on the agenda uh but thank you for the feedback it's duly noted and uh I guess I will spend some time next year just trying to figure out if it's really worth it I mean yeah if it's indeed not saving anything U might not uh yeah it's not worth bothering it bothering doing it but if um yeah if we get into let's say 10% 20% whatever um yeah we can have this conversation again but uh yeah once again thank you for uh clarifying all those all those points okay uh moving on sorry bring my notes uh so block has op

code how do we get statelessness to play nice with it uh which is an OP code that can be used for those that don't know to query the hash of the past 256 blocks but in a stat list World it cannot be assumed of course that clients will have these past 256 blocks so for a stateless execution of blocks that would me a client would always need to wait uh around an hour approximately uh few potential Solutions include mappings in the witness uh though this will of course add a non-trivial amount of extra data to the block size something like 32 bytes times

256 uh another potential solution is we can move the mapping into the state tree we can get more into this as a potential solution uh and then lastly before we get into discuss question uh hoger suggested as a potential uh option worth discussing what about lowering the block hash range from 256 to something like 50 blocks or less which would mean stateless clients only have to wait 10 minutes or less uh though this likely also will break existing contracts um so yeah just by way of introduction uh gu hand it over there gon did or

anyone else any thoughts on this uh I do have a comment that actually uh you don't need to put every single block hash you need to only put in like if you choose to put the Block hashes in the witness you only need to put those block hashes that uh that you are accessing during block execution so I know there's a bit of a finicky uh aspect because how do you prove that this block hashes are correct uh but yeah ultimately you only need to pass those block hashes that are required for execution I mean we could simply put them in the state right like we could

have an address where we just always have a um sort of walking history of the last 256 block hashes yeah we could do that address would be would write one location every time and like whenever you read from it um you would like yeah add a proof so like reading would be quite cheap it's basically just like reading a warm address but so because you need okay currently you need 256 values so you would want to put 256 hashes in oh and that's what ignasio said about Ring

buffer I get it uh so you would say uh yeah you will only replace one location at a time and circle through right exactly okay that's like the stand like I mean in the beacon sham speack we have a few things like that I think we also have like a history of last Lo hashes that works like that uhhuh and um okay that work but then if you only so you okay into the witness you would only add the latest block hash or the previous block hash and then uh any extra block hash that you that you uh readed and yes correct what would be the

extra like the stem for this like could we pick something like no not zero because people could write there like what happens if someone yeah well you can't write at zero you can't well yeah exactly you can't write so there's have to write a pre much but yeah like we could like just Reserve an address for this okay um but I mean I'm not sure that's I mean like I think vitalic tried this for the like he he was like oh we should establish that we can just put stuff into the state when we introduced uh the EIP 1559 like mechanism for the blobs and

people really didn't like it and I think it's basically replaced by just putting it all into the block header which I mean I think like I I don't actually think that is the right deism um but that was the Practical outcome that people really didn't like this extra complication of putting stuff into the state but here it's a bit different because it's like a lot more data right it's like actually a few kilobytes so it wouldn't be practical to just add all of them to every block header for sure you could also simply add one pay commitment to all the block hashes to the block header that would be the alternative if you didn't want to add it to the state

and then you would just prove it from there so like it wouldn't be at a random State location but like out of band and extra pay doesn't commitment right yes so that would be an extra block field okay and then you would so you would pass a second proof Pro to open the the person commitment uh and you would it's actually not an extra proof you can like I mean you can open any number I mean like our multi prooof is universal right it's just a proof for opening many different payments right so yeah but it would be added to the witness so it's kind of weird if we did yeah um if we added it to the block header yeah so like I think

I feel the more elegant version is to add it to to the state yeah I agree yeah it would be quite cheap although I mean I guess it's a bit attackable because people could just like try to make that particular address as deep as possible into the tree somewhere um which we know has limits like it's not going to be terrible but like yeah it's going to make our witness a few hundred bytes bigger I guess so the end of the R st that but if someone you say it's tackable but if you write the the new block hash at the end of the of the

block then someone could try to oh yeah you mean okay someone could try to write to to similar addresses I mean they would just basically make the tree much deeper that would be the attack like you try to get write lots of stuff that's as close as possible to that address where writing stuff and then like instead of being depth four or so which would be like probably like if you just had a random address it would suddenly I don't know what's the best they can do probably like 60 bits which is 64 would be like yeah maybe de age or so in St so that's not a big deal if they do that

yeah uh also I was thinking I mean it seems like adding to the state seems to be the most elegant solution but um whenever I think this means that for a stateless client to validate a new blog it should also have the previous blog hash from somewhere where now we were only thinking about the because I guess in this current block the previous block hash is the thing that gets included in this ring buffer right um okay wait but doesn't okay but you have the previous block hash because

each each block like contains the previous block hash anyway right yeah but when you are starting from scratch I I mean no no block n contains the block hash of block n minus one right but when you start when you are status client that you start from scratch yeah you should have the previous state root from attracted Source because you you haven't really verified that block you are kind of starting now okay so okay fine so let's start let's assume that you get Block hash number and and yeah okay yeah okay

so you start you start verifying block n+ One n Plus One will have the block hash of N and yes yeah so you can use that to update it right so like your starting data for validating this n plus1 block should be yeah the state root of n block n and the block hash of State n of block n you you like until now we only expected the stateless cl to get the state root of block n from somewhere but this also adds the

condition that you should also have the block hash of state of block n right because you will need that value to mutate the tree in Block n plus one but if you have an old block it will be also part of the sorry if you need to access hash will be part of the witness right no no he's not talking about that but the the that for for for this M plus1 Block execution you need some data that is outside the evm world is a write in the tree from a block hash value that you don't really calculate in the evm it's like oh but

okay so igna I think like this is I mean you do need the block hash any like I mean I think like this you you do start from the Block hash because otherwise block n plus one could build on the state that you were given but not on the Block that you were given which is also wrong that would also be an incorrect chain to follow so in all cases I think the correct thing is actually not to build on a state route the correct thing is to build on a block P yeah okay yeah that makes sense yes um and actually if we want to see blocks in complete isolation not depend on the previous one then we should just put the old State root and the new State Route

into the block right okay so so actually think this like if when you valate block M plus one and if you take as your starting source of Truth the state root of that block it is true that that State Route actually is like the state of the world on multiple potential blocks that have the same state route but this condition actually constraints not like every potential block that led to this previous state but actually a concrete block which is interesting well the problem is rather

that the following block can just like only build on the Block rle route sorry on the state route but not on the actual chain which is invalid so the correct thing is we want a block that builds on the actual um uh yeah that builds on the chain and yeah there's always some things like I mean yes you do need I think like maybe yeah we probably need the complete header to be honest because yeah you always want to verify that some conditions between two different blocks are fulfilled and even with statelessness you still need the header chain for that like yes you do always

want the condition that the post State root of the previous block equals the pre-state root of the next block right that's a fundamental thing you want um and there are more conditions like that for example there are all these E1 1559 values that need to be updated correctly and um yeah yeah and another thing I wanted to touch on is if there is any other op code that have this kind of stateful uh assumption apart from block hash may have the same problem right so I guess we need the same kind of solution for that

one so for what the for Denon for post Denon you also need to be able to provide the late the last blob hashes uh wait is there an OP code for that uh think so I'm pretty sure there's um there's ANP for I yes I know that uh for the blob PES I think they are I mean the way I specified it they are they are um per transaction like you can only access the one that's corresponds to

your uh to the transaction that was included okay I I'm not aware that that has been changed uh that's not what I remember reading but I okay I'll uh I'll look it up see if it's really I don't think so it should be within the same lock y but it would be worthwhile for someone I mean yeah we were like I also wasn't aware of uh block hash so probably like it would be worthwhile for someone to go through all the up votes and see if

there's anything else that act with this historical stuff okay uh in the last two minutes do we want to quickly touch on the vertical verification pre-compile FM you want to save that for next time uh yeah I think it's getting a bit let's um I I have to add some update to it so let's skip it for like it's only in two weeks so we can uh we can touch that then okay yep and reminder for everybody

we will switch to every two weeks going forward like y just mentioned okay anything else in the last minute otherwise we can end there okay great thank you everybody oh caros so does I explain was one is yeah no worries okay thanks everybody thanks bye thanks everyone bye byeone bye