Verkle Implementers Call #10

Transcript

okay I think we can get started welcome to veral implementers call number 10 this is issue 930 in the PM repo uh starting off with client team updates would anyone like to start I can start uh this will be the first update from from the tech team here so the good news is that the work is in progress uh finally it's been a while now I was expecting to have a faster update on our Branch but seems

like it's getting a little bit slower than expected but the work is is ongoing and um hopefully soon we will join devet don't know currently know when at the moment I'm not directly involved in it I'm great reaching Dimitri who is working on it once I got some kind of feeling from him I will share with you that's us thank you anyone

else um yeah I guess I can go next uh right so there was the holiday so not as much progress as hoped but nonetheless um Perry and I worked on the shadow Fork um there's a lot of uh issues that got fixed and uh yeah I'm currently fighting with one I hope it's the last one and um otherwise yeah we're going to prepare an update to to relaunch ctin and so we'll talk about this as part of the main agenda I guess um there's been some work on the tooling to help the test team but I I need to sync up with them and otherwise yeah there were some

updates needed to the to the EIP to two eips the one with the the state verification contract um yeah and the other one is the gas cost um the thing we discussed last time so uh both of them need to be updated and yeah that's that's all for me uh ignasio did uh do you have anything to add no no no yeah I think I can go next so uh I majorly focused since like a lot of people on holidays and like we were not

relaunching the test net so we majorly focused on uh like correcting small small issues that that were there with the another mind client implementation so now uh like another client can basically produce blocks with proofs on the work test net and the stateless uh node is also working properly and the major thing is that I was also able to test veral sync and the ranges sync part works are quite okay like I created multiple test net using cutos and tried on like multiple location and it works every time I was not able to test the healing part because the test n was not big enough to actually reach the healing face I just trying out different tricks

to test the healing part but yeah the sink the range of sink part is working perfectly so yeah that's it from my side okay I can go next uh for Aron uh I've been able to sync up to a certain uh block 7196 I think after that there are some self-destruct uh op codes that uh it's not really matching up with the veral rout uh so I have been stuck on it it seems like uh there may have been a code

misconfiguration uh compared to get so I would probably try to replicate that uh misconfiguration in Aragon to try to snc to the tip uh or I'll just wait for uh the next uh set of changes to disable uh self-destruct uh following from a short conversation on uh the test Groupon element with Gom okay I think I can go next so as far uh for the ners client we were working on the veral tree repository all of the

veral cryptography is finished and thanks to ignasio he gave us the N test vectors we identified few of the issues uh which we were facing in our uh the Primitive library that we wrote in Constantine we fixed those and now the try is pretty much ready for computing the root commitment but we are facing some issues in the internal node or due to copy on right we were uh following the uh get like the goal implementation so we are currently debugging that and we are aiming like uh in two weeks we can look for the correct like root commitment comput and yeah that's all the update like after the holidays anyone

else not sure if B is here yeah I can give an update for ethereum Js yeah cool so I was out last week on on leave so I'm not up to date with the latest developments but since gender is not here I can give an overview of what uh we've been working on uh so we're progressing on U andc and uh sying We've made it past block 13 which presented some hurdles for us so we got that working we've enabled a pre and postate verification so we can make sure that we EX the blocks properly uh We've run into some uh we

initially run into some issues related to gas costs but now that seems to be fixed uh however we also have an issue at the moment where uh sometimes there's going to be instances where balance uh is going to be accessed but it's not part of the witness uh for example contract creation I think so yeah we're just debating if we want to handle uh like undefined balances or set them to zero in the Constructor um but uh yeah we're making progress and I think this week should be could unblock us as well since I'm back that's it for us I'm not sure if someone else from eum JS is here and would like to make an additional update

but that's it for me and uh for B uh latest thing that happened is we were able to compute the state route and to follow the chain but only first 12 blocks then we had some issues uh Karim will will will uh try to give more information about that but yeah that's it we were able to compute the route and yeah that's it for now

no problem kareim I just saw your message in chat did you want to give any other update for Bas Dron already gave a brief update no worries if not cool uh okay we can move on uh so next up a update on snaps sync is ten here oh oh yes sorry I think

sorry yeah so I think I already covered it during the client update it's just that like uh we tested the voal in the ranges phase uh it seems to be working fine now I'll start testing the healing phase the the second pH of the snaping yeah that's it okay great thank you didn't realize we have already covered it perfect okay we can keep going then uh veral testing I think we have a few folks here from the testing team that wanted to potentially share a few thoughts sorry could you hear me oh no we could not but now we can y I think we got you

now you s uh I can hear you but very quietly okay it better it's a bit better now yes sorry yeah I want to shible I was no problem I yeah okay sorry so no no other update I just wanted to share quickly so uh regarding Theo uh thanks to Dragon we we have a valid State frot for the Genesis block uh so we started to sync bod in order to check the other block and we

have a problem on the block 12 uh for the moment we we think that it's related to gas cost um because uh we are not implementing something related to gas gas modification in bzo yet so it can be a problem with that because the block 12 it's the first block with a transaction so it can be related to that um so we found an EAP regarding the gas cost modific ification for their so I shared that to Gom G said that it was a good version maybe need some update I don't know and uh so the idea is to try to

implement this gas cat modification in bzou in the next week or maybe this week I'm not sure and also with thas we decided that the next modification regarding the V Tre library in bzu will be to optimize performance because for the moment in order to commit the root Ash of the Genesis Block it's um it take 15 second so it's really slow U but uh we have some ideas in order to fix that so yes we are we are still moving forward well thank you awesome

okay uh so yeah uh testing team I think we have Spencer here and and maybe Mario as well yes um do either of you want to share a few thoughts yeah I can go um can you can you hear me yes perfect yeah basically just well this is the first time I I've joined this this call so uh hello to everyone um I guess um the the we don't have anything to concrete to share but but um what I would like to know is uh just how we can um improve the current testing framework that we have to

include for example um a specific test fixtures formats for for baral so at the moment we only have two so we have the blockchain test and the St test this is good enough for most of the cases but um we can create more uh basic formats to to to test specific things about Burl but uh at the moment I I really don't don't have a a complete idea of what could that be um but but yeah that that that was basically my my goal in this call to to gather some some insights of what the current state if you guys already have test pictures for that we can we include them in our framework and and so on so

forth um yep yeah g uh yeah so my first question to you um would be you know Dan and I had a quick exchange about modifying um TN t8n tool like that is part of uh of of gu or the GU executable Suite um is is that something that is that that you yeah that you had in mind or do you need another kind of tooling for us to

to support you so I know I know you're asking the other question like how you know what we need and I have some comments about this but my first question would be that thing that uh that we talk we discuss with Dan is this is this the what your is it still current basically do I I need to keep working on that yeah of course I mean uh to to to my to my opinion I think the transition tool already does a lot of things U maybe too many but I we can we can easily generate this the blockchain blockchain test and set test for veral using the transition tool as is right now maybe just outputting more Fields but do if if you have in your mind

something that would be better as a separate tool I think that that we should go for it it doesn't it doesn't matter for for us we can use another tool it's that that's perfect um so do you have something in the transition tool that could be better um that's separate tool okay I think it f we would just need to expand the tool to produce proofs and yeah what I was getting too uh I mean the reason why I also asked that yes is precisely if we start producing proofs as well would you be able to in your framework would you be able to compare you know like imagine the block having some extra fields um although there won't be a block there

there would be something on the side but um sorry there won't be a block field there will be something on the side could you also match you know the results based on uh uh yeah so we would be exporting the witness could you also match the some values in the witness as well so yeah maybe maybe I can explain a little bit how we use the transition tool right now so um we use it to produce both of the formats and we can use it to produce a third format if that that's okay we simply call it with the prog and the trans transaction that it needs to execute and then um and then um when for example when we are producing the blockchain test we use some of the of the of the fields to

produce the production test and then for the state test we do a different approach but this is basically just the same input same output and we take whatever we need to to form whatever fixture we need um so I guess it could be very similar to this so we um I'm guessing that we need to produce a preall looc and then maybe some other extra info to the transition tool and with this we can take another field maybe the the witness and then we can put this at third uh test fixure format which would be the witness test fure for for example um yeah it's definitely tool and I don't think it's too hard uh for us to just get another source of information uh if it's another file or maybe it's another field somewhere it's

it's it's just fine we can just parse it and then just produce a Json test fctory format because ideally this third um test fixure format would be another Json file and then the clients could consume this just as they consume the blockchain test and the state test it just would be H they they would need to implement another uh consumer that that that's true but I think I think uh that's that's that's good okay well that sounds good yeah uh the other use I would have to that would like to test and in fact it's a fairly important one but it's also more difficult it's the transition like you start with a vertical vertical route right or sorry you start with an um

MPT tree and then you convert it to veral um so that would be a bit like your state route except you would be testing two states at the same time uh yeah do you basically what what could you use to test this yeah so yeah so we have the we already have something like this so This these are the transition uh Fork transition tests so um the the transition tool does is not aware of this um but the blockchain test format does contain the for the network and Well normally it contains like Berlin London whatever but sometimes it

contains the London to uh to marage for example at some point Point um I I was thinking that maybe this could be good enough so for example if we uh do Shanghai tole in Block whatever we can produce a blockchain test format that contains a lot of or many at least uh blocks in the previous fork in Shanghai and then we can just get go get to the to the bural fork block and then keep producing blocks and just keep testing for the for the transition of to verle right in in that same test because just to be uh just to make sure you're aware the like unlike any Fork before before

that this Fork will take more than one block to to happen yeah definitely we we can have as many as necessary if we um the prodction test doesn't have a limit on how many blocks we we can produce and we already have many tests that produce a lot of blocks after the fork so I I think I I mean unless you're talking about thousands of blocks or more than thousands may I I think it should be double still um but if that's something that we have to have in our minds or or how many blocks are we talking about after depends how much the state the the start state is how big it is but yeah if if uh if it's 100 megabytes um it might

take I don't know maybe a thousand blocks something like this yeah I think I think we at least for this format we should have in mind that we are testing like specific parts of the transition for example um um we for example one test could be okay we are testing this account that has balance but has no code and then go through the transition and then for this other test format sorry test uh test Vector we we go with a with an account that has code but no balance or or something very specific like that um instead of in int I uh test cases um yeah just just to test scenarios I mean we can we can produce big very big blockchain tests uh

if if it's needed maybe um maybe it's necessary anyway but uh but in my mind that's that's more like the the the idea we have to have on on on the transition uh tests that we produce yeah okay yeah uh indeed like what would be interested is when we identify Corner cases try to make sure they happen and then produce them so we don't need it's true we don't need a lot of um a lot of state to transition in one go but some stuff happens because the state is pretty large so yeah it would make sense to also be able to handle larger States

but we're we're not shooting for something that is as big as a main net of course or even a test net um what what's interesting is to see if the iterator HS uh halfway through blog um sorry halfway through contract storage or you know this kind of um this kind of use cases uh but yeah no I don't think it needs to be very large so that shouldn't be a problem if you can handle a thousand blocks I think it's more than we need yeah and we can try it I mean we can try some tests with a very big state as at at the beginning before the transition um to see if it's sustainable if we can have such a big uh test in in

in in a repo uh we can try it anyway and give it a go and see if it's if this is the right place where to have this test or we have to move it somewhere else it's it's it's okay uh one question I have is when you fill those uh when you create those tests is the data like hardcoded in some file or is it generated randomly you we can do both if if you need some random I mean we can have we basically use Python so you can have a generator of a generator of any kind you wish um can be random can be um something hardcoded or or whatever whatever is needed okay cool yep that's uh that's all I need so I

guess I will uh I will continue working on that with Dan or anybody else if uh if they want if they have question or want to join uh but yeah for me uh that's all the questions I had so I I wanted to share just a link uh to some of the text test formats definitions specs that we are working on so this folder contains a branch this does not merch yet but it contains the two examples of the stat test and the blockchain test I think we can take this as starting point if you want to generate for example the witness uh format uh or something similar and and we can just begin to to write out um a new format in in in this in fashion if

if we need if we need it yes Spencer hi guys yeah I just uh wanted to ask um the vertical test vectors that um ignasio has I think there's three different types would there be any benefit of us having that within our repo from your end like a tree test where um yeah you're adding the key value pairs into an empty vericle tree and then verifying the root hash um similar for adding just accounts into an empty tree and verifying the root hash because

we could definitely add that into our repo as well if it's of value and I'm not sure how far along a lot of people are yet and just from the perspective that um yeah the blockchain tests like it's amazing that we can use them already somewhat to test verticle but um the only real thing we have is this isn't working because the state route is mismatched um and it makes it kind of difficult to find specific Corner cases in that sense so if there's these types of formats that we can add in the repo that are more lowlevel um I think we'd be happy to add that and the only kind of precursor would be that clients might have to have an additional tool that we use within the repo as opposed to using T10

exclusively um yeah I think it will make sense to like use those so I have this um cryptography test vectors uh which I don't think are related to this testing infrastructure so um other libraries are using them in the format that I created them but for these other Des spectors about the tree inserts and expect the stay roots and things like that I think it would be useful to import like the test case itself not necessarily the format we can probably adjust the format to whatever exist now so we don't have to create any new

custom thing because I'm not sure most veral Library have been using these tests [Music] um but yeah I will just simply Leverage The whatever thing I created for testing uh not really respect much the format that's not really that important okay anything else on the testing

subject U I guess one last question could be is there any um open PR for the transition tool for Burl or is there anything we can take a look maybe the main the main thing is because there's no formal definition yet for the transition tool so it can can be sometimes tricky to um to really know what what the testing um testing framework is expecting from it but I it would be great if if if you guys have any progress on that I I can I can take a look if and some feedback if possible uh so you want a PR that goes through the transition basically is that what you're asking for no for for the transition tool is is there any any PR

or is already mared or or there's a PR yeah that I can I mean at least against gu that I can send to you okay great yeah that that's exactly what what I what I okay uh next up a new test net and reviewing things to make sure that we include what we want to include for example the recent fix to the main storage offset bug um gon did you have anything that you wanted to start with here uh yeah so there's been uh several issues on the test net that we

identified I'm trying to currently collect them um yeah so indeed there's the storage offset issue there's the fact that self-destruct is activated so that was a rebase uh problem on my end uh so yeah currently self-destruct works on on the test net and it should not um there was uh what we discussed last time not charging the gas uh from the transaction origin and the transaction like destination the the two and from fields of uh of of the of the the transaction so that the gas remains uh

21,000 uh like the gas for a simple transaction remains 21,000 and then I had an extra a fix I'm trying to remember what it was uh it was uh yeah so it was something that gender pointed out that when um when the the witness uh sorry when account does not exist um it seems that the two address is not being part of the witness so there's there's a bug that needs to be fixed um so I will fix that on the guest side I assume most that's that's only a problem that affects G but uh yeah I was

wondering if you guys if there was something else you were aware of uh that I should also add to the scope of this relaunch yet Anish uh if you remember there was some problem with one transaction that like uh there was a out of guess error but the code still keeps on executing if you like uh in the current question Des I remember that and yes it's uh like the fix is already in there so that's why I didn't write it down but yes um it's it should be it should be uh added to the list thank you and uh one more thing I'm not sure if we finalize the decision in this but I

think there was a discussion around like when there's a empty block do we add the guest beneficiary witness or not did we have a decision on that like I'm not sure about so when there is an empty block and uh no I mean when it's an empty block sorry help me here uh it's when there yeah so like for example we produce a block or like we produce a MP block so there are no transactions so in the execution witness should we add the guest beneficiary to the execution witness because right now it's being added in the current testet so like

should we keep the same behavior or like should we modify this Behavior right the so the fear recipient so that's when there are no withdrawals and there there's no transaction so basically nothing um nothing uh yeah no reward gets given so the point was should we add the the witness uh yeah I'm not sure where we decided my my hunch is that we should not really bother about you know removing it when it's just null null but uh I'm trying to remember was there any other point in that discussion that I'm forgetting

I think it was just mainly that and maybe if there there were not tips like any case that will cause the balance of the coin base not to change um I think in the spec um the coinbase state is only touched if the balance changes um and now we have simply retouch the coin base so it's always in the witness yeah like any case that won't change the balance what what I'm just wondering sorry okay that's see okay um yeah what I was just wondering is how a stateless client that

doesn't have you know anything in the tree would react um is are we are we going to create annoying bugs for for no good reason I mean I don't mind removing it it wouldn't be a big problem I think I'm just uh saying U yeah it might it might cause some annoying Corner cases but I don't mind I don't mind removing it if that's all it takes yeah um I mean nothing comes to mind I'm just wondering what happens if you get an empty witness but I guess it's also an excellent test so okay let's let's try to do this and if uh if it causes a problem we we'll figure it out and we'll return uh we'll return to the old

version cool thanks uh anything else uh ignasio did you have something you wanted to share BL cash uh oh yeah I sorry uh I created uh since there a lot of new people here now showing the call uh I did a small slide presentation to share now uh to explain this Blog has situation that we haven't resolved yet uh so it's kind of a a hole in the spec uh we discussed this about two

months ago in a single B call and just like exploring a b the situation so I will share my screen and give a refresher on all these topics so we can maybe get closer to making a decision so give me a minute um can you see my screen not yet nope yeah not yet okaying it's happening can see it now okay um so yeah I will try to go somewhat

fast because I want to take a lot of time here um so what is okay so what is block hatch just like as a quick refresher is um up code that allows uh a contract to retrieve any block hatch within the last 256 blocks so as an example if we are in block number 1,000 and you ask block hash of 998 you will get the corresponding blash and if you ask for something that is not within this range it will return zero so why is this a problem for Bal trees and the problem is that these

block hashes aren't part of the state and um which this means is that um this data is can't be in the execution witness so a stateless client that receives an execution witness which in theory has all the data that he needs to execute the block won't find these Block hashes in case this block contains an block hash upod so yeah that's kind of the the the the main question or the main problem that we have to solve um now some minutes ago uh when I was doing this presentation I realized that

there was already some attempts on targeting this problem in eips which is interesting so one of them is EAP uh 210 U from vitalic from a long ago so I have it here so his goal here was mainly to solve this problem so store Block hashes in the state which obviously will solve the problem uh to yeah reduce protocol complexity and all that but it also tries to extend the range of how many block hashes you you can resolve so I think that the original intention was uh to store all the Block hashes in the state so later nodes can

prune some history but still have like the blash reference so if this data was stored somewhere else you can still validate it uh there's also this 2935 VIP which is an evolution of 210 uh so I think it contains some simplifications has some um yeah mostly that and there's also a e research post um from 2020 which is basically making the point it's pretty short so it's

basically making the point that yeah the blash um the way that blash Works will be a problem for stess ethereum which is obviously the case because we are here and so yeah just to give you a some context this is not like the first time we discover this problem but it it is just that now it's important because we have to solve it to move forward so like in the previous call we kind of sh directly into some potential Production Solutions but I wanted to go a bit slower here and maybe do some thought experiments about other potential Solutions and why they work or wouldn't work or which are the

trade-offs so if you think about this problem from scratch and you say okay so um if this block hashes are in the state maybe we can like simply attach them uh as extra data in witness and whenever a stateless client executes the block it will find find an up code that it's like a block has and you would say oh okay I need to block hash of this ask block and I will find it in the witness in this like extra data field or something like that so the good part is that this sounds simple because yeah it's in the witness but not part of it's not part of the tree but it's like an

appendix of data and the B part is that it isn't verifiable because like someone simply put some data in in the w witness that you cannot really verify and this won't be verified as part of the veral proof because the veral proof verifies data in the state and this is like an appendix of data so it's like trust uh you have to trust whatever is put there so maybe if you think further you might say okay so if I I'm verifying a block and um this block has an expected gas usage and an expected state route that I want to verify what is the chance

that I can really put some fake blash and still have the gas uh the gas I'm sorry gas usage and state root validate anyway because if I kind of fake the block has probably something the contract execution might execute differently and shouldn't match and the reason at least that I found is that just like an easy example is to say that maybe the contract only uses the last eight bits of the block has because he's using the block has as some kind of random source which actually will be a bad idea but

maybe it's doing that so if it is using the block hash result of the op in that way you can simply fake the the other 256 minus 8 Bits of the block hash and everything will work correctly and the gas usage and state rout will still match so this isn't really like such a crazy use case so um despite you might say that you were given enough data so the state transition could be validated which is true I would say that the data that you had in the witness wasn't 100% correct

so like were you expected to receive the block hash for some block number uh you got something else which is completely wrong despite that was enough to Val the state so I know I think it's a bit messy and not really that nice so I don't think this is like a good like argument or like I think it's like an unfortunate situation of the solution so let's like to move forward the potential idea is to say okay so instead of having this data from an like trusting this data from an unrusted Source why not use the CL uh to get these block

hashes um so the good part is that like our assumption is that the cl is trusted because you are using it for deciding which is the right change to follow and that will like never change in a way because the stateless client is only validating State transition and not really like following the right chain uh since you will ask this party for this data you don't have to add anything extra to execution witness which maybe sounds nice and U we have this situation as I mentioned before of partially correct

values or something like that like whatever value we get from the CL we will assume it is correct uh the bad part is that at least from my perspective is that we are adding an extra expectation uh to the party that is resolving us the consensus problem so in this case the CL so like until now the CL is was mostly used only used for deciding which is the right next block to validate and that's fine and that won't change because it's kind of the minimal thing the minimal expectation but I believe that if in the

future we can have stateless clients that won't be using CLS because they are trying to use some other solution to follow the right chain whatever that is um we would be like adding this extra expectation that this Al solution should also provide a history of block hashes uh which may or may not be a problem but I don't know I think it's just better to not put more expectations to like external apis um on providing us more data um I think that would be ideal I mean in the long run if we want to go stateless we would also want to make the

CL stateless right so yeah um so that's kind of make makes it not the ideal solution if we just solve this by putting it on the cl cl on the other hand we could say right now well we can't go full stateless anyway because currently we don't have a way to make the the beacon chain stateless realistically um so it could be okay to box this away and say well block hashes is something that the the can take care of and for now it solves it the traditional way which is just it isn't stateless um and once it becomes stateless it's also realistic to expect I think I mean the the CL does have a

database of block hases already like we do have this history right this is stored in the C as far as I know like um the beacon state has has it so maybe this is okay and we can simply say when the C goes stateless um it is required to um to make this data available as part of its witness yeah that's a good point um yeah I think it's more like mainly about like shortterm might be might be yeah I agree this might be something worth checking because also like like I mean in a way like I think it's a good point to point

to the CL and say the CL isn't completely stateless anyway um which is like not such a big deal right like the CL state is like hundreds of megabytes rather than like tens to hundreds of gigabytes like for the E so it is a much much smaller State overall and maybe it's better in this case to say like since we can't solve that right now anyway um it doesn't make sense to over engineer this part the question is how much how much how much complexity does it add um to ask the CL for for it so basically it would mean that um

the the execution layer request would come with an extra field providing the last 256 uh Beacon rotes is that or like well execution rotes is that is that correct or how would it work yeah I mean something like that can work and also can keep going to the next solution which might allow to mix okay I will move forward and I think I will uh directly answer this question maybe um so like the next solution is a bit that going that direction and I call this stateful tracking or keep your own history it's like inventing names here so another

idea is simply to say uh let's not trust or expect an external party to give us valid block hases and simply when the stateless client boots get the last 2 56 block headers from anybody and since our like a stateless client has as an starting axum the parent block uh because it needs that for the state rout to ex to validate the witness uh you will be in a situation in which you are trying to validate the current block which you don't trust because that's the reason why you are trying to execute this stateless you the parent block which is trusted because at your

starting assumption as a stateless client because you kind of trust the state route and things like that and you have all these um block headers that you fetch from somewhere un trusted and what you can do is you kind of Simply like check the you know the kak chain from the parent block for the rest of the history that you fetch so you can verify this history and that means that you have all these now verified 256 block hashes so you can execute this current block and if any block hash up code appears you can simply fetch it from your from memory um

that's why I call it this keep your own history because St stateless client is simply creating this history from like downloading this book headers from somewhere and after your blog verifies you simply delete the last one and append the the the the one that show you have just verified and you kind of update this history and you kind of keep moving forward so the good part is that you don't have to trust or respect anyone to provide you the correct data so it doesn't like force the ancient API or something like that to uh give you this data uh again this there no extra data added to execution

Witnesses of course the most obious bad part is that you have to download um 236 block headers uh when you boot which it isn't really that bad but it's like I know some reasonabl amount of data but you have to only do that once you would uh so it's not like on every block it's just like once uh despite we are not forcing a a specific party to provide this data like stateless clients still have to decide from where they will pull this um so it's kind of yeah um making the stat client just

deal with this problem which might not be obvious uh this might be somewhat annoying for I what I call short-term stateless clients so let's say that I know metamask won to embed a stateless client and only like verify the chain for a couple of blocks because it wants to know check if a transaction was added or some side effect was have happened downloading these 256 block headers is might be like a big pain considering that it's only trying to verify the chain for a couple of blocks uh so this this download won't be a big deal for validators of the chain that

are like long term but for shortterm ones might be a big pain and some point that um we discuss on the weekend weum that he mentioned which is interesting which is if there's a reorg and that means that the stat kind should also manage the situation because it has to do the reorg on this history that is keeping itself so um so it's nice in the sense that is like not trusting anybody else but it has this other side effects but but that might not be ideal and of course um regarding D's

last question you can also ask like in this solution as for the last 256 block hashes instead of headers and see we keep your own history and just ask once and just the stateless client can simply keep the the the like this history on every next block so shouldn't be need it for B like in every block as for for the history and the last solution which is the one that we actually discussed like Tom months going the call is this state ring buffer which is okay let's buy the bullet and simply put the last 256 Block hashes in the state Tre uh because if it is part of a state

three that means that it will be automatically in the execution witness and the status kind will be happy because there's no magic or extra work that should be done by them so like there are many ways to implement this like the most obvious one is to Simply Reserve 256 address in the tree uh this should say FF I guess so um just reserve some addresses uh before any transaction is executed in a block using simply update this um the the the parent block hash in this in the corresponding address which you interpret as a ring buffer so nothing

crazy here uh so after you do that before executing anything you have the updated ring buffer so whenever you see a block hash or some BL number if if it is not within the range return zero and if it is within the range just simply uh take the blog number mod 256 that will give you the address and simply read that from the state uh another example is to instead of like fixing these addresses just create um create a like a system contract uh this is something that I got to know because gajinder mentioned that

this is the kind of solution that was done for putting in the CL um putting in the L um CL um State Roots I think he can mention that later but yeah that might be a cleaner solution to make some kind of system contract so like for the long long term I would say this is like the cleaning solution because uh the block has data is part of execution witness is only added when it's needed like if a Blog doesn't have a L hash up code there's no um extra data put in the witness and for stateless client there's like zero extra

work or complexity like they don't have to deal with pulling external data or dealing with reorgs or whatever and yeah the bad part is that this the the implementation that has the highest complexity because we have to change with the Tre design and Reserve these addresses or create this contract and something that was mentioned by D in like this call from two months ago has this potential DS Vector because like for example in this example all these keys are in the same Branch so I mean people can have a lot of time to really um you know kind of root Force keys rights so this branch is like longer than

average um if this is like a problem or not I guess it requires like a more formal analysis but uh it's just to point out that um this is like this attack Vector wouldn't be a huge deal for the block hash execution because probably clients will have their only memory ring buffer so they won't be reading from the tree but for execution witness size this Branch might be longer and for updating the tree you might have to do some extra commitment updates in that Branch um but if that's a problem or not um I don't know maybe we have to think more about that so yeah that's all the presentation so hopefully this will

give like a high level view of the situation uh yes Lucas so just my quick comment from the chat that e 4788 already push hashes though uh Bon Block hashes in the state so so if we implement it in the state as EAP 2935 we will have feuture parity here yes this was like the AP that

gajinder told me yeah exactly um yeah I have some questions about this uh EIP uh first of all the address clearly uh I don't think we can use this one because it's a it's the system address uh yeah I wouldn't want to use that one um but what I understand is that when you're storing something you actually need to execute some bite code instead of writing directly in the tree is that correct no it's not correct though um in the rational but yeah okay so for example with EIP 4788 mhm uh um most clients went with executing a bite code a transaction but

for example in never mind it's implemented by currently uh by directly writing to the state slot right uh we are thinking about changing it but even in eum JS we directly write into storage slots and B someone else can access it with with the contract mhm so it's uh implementation detail well yeah but it's an implementation details that actually matters because if one one client you know executes code you will find it it will have to end up in the witness and then another client will not execute that code and so we'll find that the

witness is larger than it needs to um yeah so I I think i' I'd be happy because okay okay I'd like to relaunch the test net I could implement the CIP but I need some more clarity on this um like yeah can we decide yeah UK so will system transactions end up in the witness then or do you mean Witness by loading stuff from from the state I mean my my understanding is that unless the contract is somehow available in the in the stateless client it needs to be in the in the in the witness yeah I mean we could also not put it in the witness

but yeah stess client won't update the state right so it's like uh transparent to them so they they need to update the tree okay um but I mean okay it's true that they don't need okay it's just that we were discussing uh you know an extra check to verify that the WID in order to avoid an ex some special kind of attack or at least preventing people from sending bloated Witnesses uh you would check that every leaf in the tree that you've been sent uh has been and like that you've been sent and then

ended up in the reconstructed stateless tree would have been accessed otherwise uh you would declare the the witness invalid that's what we were thinking about it might be too extreme but yeah okay there's a potential consensus problem here um but I guess yeah it could be circumvented by saying well the the witness uh the witness doesn't include the system contracts but there's always the risk that if you for whatever reason you upgrade the system contract uh you might find yourself with some uh some complexities the S system contract is like this is to record the state rots yes but like does it like if it's is it part is it part itself of the

state route like does it does it State affect the the um the ethereum state yes the system contract is part of the state rout yeah yeah but then but then it's clearly part of consensus right then everyone has to agree on it exactly I mean that's the question yeah yeah but I mean that is clear like and then if it does affect the state rout then we also have to include the witness um because otherwise the state of Cent will not be like able to compute the like verify that the state rots have been updated correctly so yes like unless they package the the contract by you know in in yeah they package it

themselves and they don't they don't actually uh put it in the tree but yeah know I think I think it should be in the it should be in the list it should be in the witness sry yeah you uh there's some interesting um case here in which like whenever we add the parent block hash in the ring buffer this parent block hash actually is already it's like data that stat client already has because it already needed the parent block so in theory like this right in execution withness shouldn't be needed but it's just like a single key so maybe it doesn't make any

big difference but uh this is a right this is data for a right that the stess clients already have even if it isn't part of the okay um all right we're a bit overboard um I don't know if yeah I guess we have to to push the the rest of discussion to next time but um when uh okay so what I what I suggest is that I will try to implement uh 20 2935 in in G for for this purpose cuz I don't think we have it and if we find any problems we I can bring them up at uh at the next Vic but from what I

can see uh we should relaunch ctin and with with this method because it's already defined so let's give it a try okay cool U yep sorry for a few minutes over thank you everyone there were two topics we didn't get to uh one is Prague Electra planning uh which obviously is still ongoing and is a big topic I would just encourage and remind folks to join the next ACD acde uh and then there's also agenda item today for migration strategy which we can get to next time or continue async uh okay awesome thank you

everyone talk to you next time thanks bye thanks bye bye bye bye