Verkle Implementers Call #16

Transcript

okay let's get started hey y'all welcome to veral implementers call 16 this is issue 10005 in the PM repo uh the agenda will be shared here in the chat momentarily uh starting things off with client team updates anyone up to start things off a yeah hi a from the members seat one team so the last two weeks we finished implementing EIP

6800 that basically uh captures the entire world State into a unified voal Tre uh we tested it entirely with uh get and for cor correctness and consistency and uh everything works to like seems to work fine uh then we updated the new spec change for point to hash and uh we incorporated that as well and still all the test data seems to be consistent with get uh apart from that uh in our inmemory nit verle like verle tree implementation we have have almost reached full statelessness uh we are

just uh left out with the tests for proof of absence those conditions apart from that uh we are pretty much again correct and consistent with all the test cases of go and uh we also benchmarked them like not very uh solidly but uh we were just wanting to estimate uh the speed and uh they look decent uh so far uh apart from that uh the major hurdle for us in integration is our entire accounts layer is very like under the hood integrated with our database and um it's very much dependent on the storage

try separately which is giving us a hard time to refactor the code uh if it's like if if we spend too much effort on it I guess we would shift to a path-based storage yeah that's pretty much the update nice uh just a quick question when you say you have the same like it's consistent with gas you're only talking about the root computation or do you also get the same gas consumption no no I'm just talking about uh testing it with the test vectors because we haven't fully finished the integration yet yeah yeah okay cool thanks it's already pretty cool thank you very

much okay well I guess in some un muted I'll go next uh yeah we've been we've been working on tooling uh we helped other teams with the the interrupt the test net interrupt uh we found some some problems um some of them so for example um gu did not use the map to field that was an accident it's entirely my fault so we're going to to relaunch the test net at some point but we're making sure that everybody uh agrees with the rest of the guest model until then um we have made a presentation at efp or EPF I never remember what it's called but the

etherum protocol Fellowship EPF uh yeah we got some stuff merged into gu so we have one PR that that got merged and another one that's awaiting merge but hopefully we'll make it soon uh nasio has worked on the Explorer we'll have a presentation about that uh yeah I started thinking uh again to guess to to some block after Shanghai so that we can produce some some metrics like average proof size gas consumption things like this that would be quite useful for um for people who keep asking about them and uh yeah there was more work on the revamp of EIP

4762 but I'll talk about this later and ignasio just updated C info because it was quite updated I think that's pretty much it ignasio do you have anything else to add no not ready okay I can go for eum JS uh so on etherum JS yeah we basically uh tested out the test vectors game has been giving us and made sure that uh we pass and basically debu some of the issues that came through and on const F five then we basically synced and found some

of the issues in ethereum JS and resolved that right now uh we are I think we are on the last mile where we are trying to resolve mismatching gas issues on self-destruct and I hope uh that is the last stage and so basically we are hitting this issue on block 261 uh and uh I think post that maybe we be uh will be good to sync rest of the test net and uh so for transition uh what we are planning right now is that uh we uh so me and Gabriel have this plan that uh

we we will basically uh code the transition in a way that even without having uh having having the meral state will basically pop off things from the Merle State and try to match the Merle straight through Straight rout uh so this is our plan to uh Implement and test out a transition and once the work state is also implemented in theum JS then which basically would be the next step uh then basically we would also pop things back pop things in the vle straight uh during transition and then make sure that we match everywhere thank you U I can go next go next uh in nether

mind we are also working on like syncing the Conant testet we synced a few blocks and found a few issues in the neand implementation uh and there is I think some discussion around the gas cost of cell distruct that is there uh in parall to that I'm also trying to work on the transition uh some part of it is implemented uh it'll take two three more days to like finally start testing transition M plan so yeah that's it on bzu side we we are working on some improvements regarding performance so we are added the the batching for generation of the three key we are also batching the ash of the commitment we

are working in order to improve the update commitment part and and uh so yes we we can see some better performance but we still have some work to do uh we are also uh finished some refactoring so the merge with the with the main branch and the block A3 is implemented we are just waiting for the new test net in order to to test the gas cost implementation and uh I hope that we will soon look at the proof validation um the B side so yeah it will be soon I

hope any more updates if not I think that was everybody we can move on to the next agenda item testing updates I don't think we have anyone from the testing team here today but uh Gom mentioned you may give a quick update here yeah so very quick is uh I'm just helping them um so the idea is that we we have this uh process that has a transition right and we we were agreeing on the tooling um for example there's no implementation of any of the veral Primitive or crypto Primitives in in Python so I added a tool to compute uh you just passed the the address and the

slot number on the command line and it will compute the the uh the key the key value for you uh so we've had some back and forth on that um and then it became apparent that uh we would still need to um to export the mapping uh from the key back to the preimage so address and uh and or uh slot number this is because it's easy for them to check that all the keys that are given are expected but if there are some keys missing they don't know how to flag what specific account was missing so there's some effort for for us to to provide such a tool to to Output the

mapping um from the from the hash to the preimage but once they have this uh we should have all the tooling necessary to to at least test a full transition so they yeah slow slow progress not uh not very impressive uh at least not not uh announcement worthy but but it's progressing nice thank you for giving the update cool next up uh the witness Explorer demo from ignasio hey um yes so this is something I've been working mostly in the previous week um last week I'm

sorry so I will share my screen so we can make this more interesting give me a second okay is this working yep okay uh okay so what is this witness Explorer thing um one of the first things that I remember when I started working in bural stuff was like this realization that the code for executing contracts will be part of the witness and a big addition to the witness um like the witness size might

depend on how much code is executed and you are going to be charged whenever you execute a contract for of the Cod chunks that I needed so clearly this will add some new like let's say Dimension into gas accounting for contract developers to understand how much adding the code impacts their gas uh for the transaction execution so what I did is okay so first of all I'm not like a web UI person so I'm sorry for um if it's not like a really nice UI but what I did is um something like a blockchain Explorer but to understand better what it's in the

witness for transactions okay so currently this is live let's call it in cin uh I deploy this like in my machine and you can access everyone can access through this um website which is like a subdomain of my site we can later like move this somewhere else um but if you want to test it you can use it here and basically the uh the landing page is um I'm showing two lists one is like the top 10 highest gas transactions as to like for people to really have a starting point and start looking at things if they

want and I have another list that I call the most inefficient code access transactions which hopefully will make sense later so uh if you click on any transaction or you look for a specific transaction here that you're are interested uh you will see a web like a page like this one so this first example is a transaction on cin that uh I did for deploying an like a like an ERC contract okay that is was like kind of real contract so the things that I show here is like well the transaction hash some

like basic transaction information like who is sending that and where and how much is and the block number um then I show the total gas which shouldn't be surprising and then I show uh like a deaggregation of this total gas into the execution gas which should be understood as like the usual kind of gas that you already pay today for things you know like up codes uh instructions and things that and I deaggregate also what how much gas comes from witness additions that aren't cold related and I will explain this a bit

later and how much gas comes from a cold chunk accessing okay which was like my original motivation for doing all this since this is like a contract deployment the co Changas it has like zero value I will show another transaction later with some more interesting um case um but at least you start to see like the idea of you know if you if you want to see how Burl changes the gas um expectation of your contract then you can start like looking at these three lambers

separately then in the execution section I show how many instructions were executed how many bytes were executed um like considering that there are instructions with more than one byte then I show how many bytes were charged so in this case it's zero because no code was executed and then I show something called that I invented the name is execution efficiency but let's look at this later in another [Music] transaction then in this witness charges section I show every addition to the witness that charge a nonzero amount of

gas okay and I exclude Cod Chun additions so basically since this is a contract deployment you will see the contract creation unit cost which was this amount of gas and then you we did some s load and s store for this contract at this storage slot uh this stor for yeah the same storage slot and then we did something else with another T slot and then you get charge the contract creation completion cost so at least like someone can look at these things and Under start to understand better or have a better intuition of where these

um witness gas cost are going okay so basically all this is trying to detail this cost and all this is trying to detail more this okay and then I have another section which is winess key values which is similar to the stateless tab in the door explorer that I think I can show now because it's it's not available uh but in the stateless tab in the door Explorer we have the witness key values that were uh added in the witness but at the Block Level so I go I I went like a step

further and say okay let's do this at the transaction level because maybe we understand um how a transaction uh which keys were added to to the witness from a particular transaction so for example here you will see that you know um this is probably the key of the contract that we created and we can see that um now we have the first you know this four last five values um have the noun the cash of the contract and things like that um other internal noes probably so

this is like a a bit more maybe detail information per transaction of the which things were added to the witness so probably maybe this will be helpful for for the buing and stuff uh um yeah so that's kind of the overall view of the UI so to look at another example that is a bit more interesting I deployed in C the um if you know about remix it has a basic project that uh as an example is like a contract for voting and delegating votes and things like that it doesn't really

matter what it does I just wanted to to have like a bigger contract and do like a longer execution of real code and basically I deploy this test contract that is part of the project and and I called this before all method doesn't matter what it does but basically it pushed something into the storage and and instantiates like the bot contract with some parameter okay so if you if we look at this transaction execution yeah you can look at it with the transaction hash um you like the basic information as usual we see that the total gas is this

amount and we see like a more interesting distribution of the cost uh in like the usual execution guide gas nonod witness gas and cod chunk accessing gas which in this case is it isn't zero because it's actually executing code in the execution type in this case uh we see that the amount of bytes that were really touched during the execution is this amount but you were charged like a much bigger amount because remember that you are charged chunks of 32 bytes so um the my point here with this execution efficiency is trying to get an

intuition with a single number of how efficient is your transaction execution or your contract design uh because like in the worst case scenario you will be maybe like champing all over around the contract and that is will be pretty terrible because you will be charged with a lot of btes that you are not using and for example in the other extreme if your transaction execution is like a tight Loop in a single uh C chunk like you will be executing a lot of bites but you will be only charge a small amount because everything happens

in one chunk let's say so this execution efficiency maybe it's like a not really the best name but that's what I thought is basically the ratio of um how many bytes you are actually um using compared to the amount that you were charged okay so ideally you want this number to be high so you are not paying for a lot of code that you are not really using how much of this really depend on uh how much of this depends on the contract developer it's not an easy question to answer uh

because maybe some of it can be controlled by the contract developer because you can think more of trying to chample all around if possible but a part of this cost is also related to compilers uh that maybe now have to understand better how to you know um maybe with some hints or something try to compile things in a way that um uh like the ex fion of at least important methods don't really shamp around that much so in the witness charges we see a bit more interesting things um so

remember that in this method we had like some storage changes and we we kind of created a contract with some parameter so basically yeah you can see some s Lo and stores you can see a code copy which has a witness uh addition that is pretty relevant I have the create of code that also chares some other stuff um you can see here the contract creation completion and some extra lows and sores later so the idea here is again all this stuff trying to shed more light into

this cost and all the staff trying to give more detail about this cost so if you already see that in this case the C Chun accessing is 4% of the total then spending a lot of effort like caring about the stuff maybe this doesn't make sense and makes more sense to just like understand if this makes sense or you can have any control in improving this but maybe if this is like 25% of the total I know maybe you want to think about something regarding cold Chun accessing and yeah well the winess key values is like well a lot of things U so something really important to

clarify now is that in the current test net we don't we aren't really um we haven't implemented the Chun field cost uh in the like in the gas accounting so um if we look at let's see if you look at the EIP you that the usual like the gas cast that we implemented in cin are this four ones you have like the the the

read cost let's say the usual right cost of the branch and the chunks but there's like an extra cost that is like the chunk field cost that we should charge every time we write a value in the tree that has an empty that was empty so we are kind of adding State and this gas is like pretty significant so you should have in mind that like I think it's okay to use this today to you know start to get a sense of some stuff but don't don't take like the current gas using contracts as like the final number because if any of this s store or related operations that add

state to the tree uh are fresh rights you should be charged with this cost which isn't negligible so please have that in mind um probably I know probably not in the next test net but maybe in the other we can think of trying to start charging that um and whenever that's the case you will see here that cost appearing too um so yeah I mean hopefully this will be useful for like maybe us cor developers trying to deag some particular difference in the gas between clients and hopefully for contract Developers

trying to you know come to C deploy their thing come here like run a transaction that calls the most you know Ed methods I just paste the hash and start getting an intuition of like what is the cost and where why that is the case and things like that um so yeah that is my presentation awesome thank you ignasio super cool okay next up gas model updates Gom uh yeah let me share my screen so

I'm just uh sharing some ongoing discussion it's by no mean the latest uh version of the spec it's to give a sense of how the how the spec could evolve ultimately all of this will be decided in U in the in the interrupt in the in the couple next month actually um but yeah just want to to give a heads up on on what will uh what might happen so the first thing um is that currently uh for those who know the spec e 4762 uh when you have a call to either any type of call so delegate call static

call B in and I forget the last one call code um you uh get like you touch the version and you touch the size Leaf key so it appears that this is actually incorrect uh we should uh so the the intuition here is that everything that touches an account touches the version the potentially the balance and the and the nons and everything that has to do with the code Tes the size and potentially the the hash um so the the modification is that instead of charging for the code size

LIF key we would replace it with a non slift key and then when you uh either do xcode size and xcode X code copy uh you would touch the the leaf the the code size Leaf key and if you call X code hash you would touch the code hash Le key um so so yeah that makes things a bit more expensive than they currently are on the test net but it feels more correct at least from a intuition point of view um just a quick remark that gu does not currently uh touch the when calling a contract guest does not use the size but it's using the hash so here when you

when you do a call uh it would make sense to touch the I mean if things were left as they are today it would make sense to touch the hash and not the the size but in a stateless context you want to know where uh the code ends so that you you know what to look for in the tree and not go randomly in the tree looking for things that are not there so it it makes sense to replace it with the with the code size um and yeah there's there was also a discussion about making it uh like touching making the touching of balance Leaf key unconditional this is because it matches the historical Behavior namely that when

you load a contract the the account is packaged together as an RP payload uh so to to be aligned to this uh to this Behavior you would also have to conditionally touch the the balance Leaf key unlike what is currently specified in which you just uh touch the balance if it's uh if your call is value sending and in a way that makes sense because something that is not specifi on this slide but there's another reason to do this it's because uh when you do a actually no sorry that's that's wrong what I was going to say is wrong so forget it um and uh yeah the the other the other reason to to

touch uh uh the balance uh actually I don't know why I wrote that sorry um but uh anyway so the the other question that was asked was uh do we need to do we really need to use version Leaf key so there was a question asked by Ginder if I'm not mistaken uh so I would say in terms of if you look at the gas accounting it does make sense because uh you currently when you when you do a cold account cost it cost uh 2600 gas and if you look at the cost uh of reading four entries so namely the version the balance the nons

and the size you get about the same uh the same value of course if you decide not to use the version it would be uh 2500 so it would still be roughly the same value uh but yeah you could also see it another way if you don't include the balance like was this like was discussed in the previous slide um you would get 20 2500 and then half the time you would charge an extra 200 so on average it would be uh it would be the same cost as 2600 uh but yeah the other reason to keep Leaf key is for forward compatibility so this is something that

is still up in the air once again I expect the resolution next month at the at the interrupt uh but we uh I just wanted to to share this uh this thinking yeah and the next uh the next slide is for is for another um another topic uh yeah so that's pretty much the the current state I don't know if there are questions but yeah don't uh don't worry if some things feels a bit uh uh too sudden it's just a discussion and uh yeah the point is to get the the discussion started cool thank you

Gom uh next up I think it's also you uh EIP 2935 oh yeah um yeah so actually it comes from the conversation it's a very sh one it it comes from a conversation at acde last week oh sorry two weeks ago um we were pushing to get uh EIP 2935 included in frag and at some point vitalic said yeah we should increase the the buffer size the the ring buffer size to uh 8,192 so 2 to the^ of 13 um I have no problem doing this uh I just wanted to collect any feedback or

people taking exception with with this but if not I suggest we try to extend the the buffer size to to 8 kiloby be there do we have any ex extra context on on the reasoning for bumping it up what was no no I'm laughing because I saw gender's comment we should go all the way um so sorry what was the question just a context for balic uh so the context is that 256 blocks is very very short and no one really cares about this short of any his story because for example if you have a

ZK rollup that needs to access uh that needs to make a proof it will take quite some time and uh by the time the the proof is ready and they would they would need the block hash to compare or to use in their proof or to verify their proof uh the 256 blocks was will already have elapsed and so extending that value to uh I think it's uh I actually didn't compute but it's U I think it's like a day or something um at least it's more than one hour because I think 256 gives you about 45 minutes uh which is too too short so

yeah that's that's the idea behind it not inflate the state all the way like gin there suggest but um but but at least give you enough of a buffer that you can take your time to produce very slow uh like proofs that are very slow to generate got it yeah I have h a question that I think we have dis touched on some previous calls so this proposal of having like a longer history of block hashes is going to affect the block has

instruction um scope or this like longer history will be only accessible through some some kind of other system contract interface or something like that just like thinking of like if this going to be a breaking change for blog hash instruction yeah it's a very good point uh I didn't think of that and that's uh I I think it would make sense exactly like you said to I mean I'm I'm not a fan of having uh at least the update being done via the evm by code but we were talking when we discussed the the deployment method to offer a get function that would uh that would be

able to that would be evm based so you would just call that uh that contract with that contracts get function and give a number that is larger than 250 while still retaining the standard behavior of block hash and that would probably be the the best approach to break as little things as possible uh yeah okay that's uh that's one item to to add to the discussion uh yeah I also saw Ken's comment uh yeah I'd be up for that in the next in the next test if everyone is uh is okay with

it looks like thumbs up to that yep cool okay uh I think next up you also had a quick update on 7545 the proof verification pre-compile I had to unmute of course uh yeah so indeed uh there's been some back and forth about 7545 so initially we wanted to have it in Prague then we decided maybe it's not necessary because optimism who was initially interested in it is no longer interested in it and

then I had a conversation with polygon about this they were interested in it and so the API that I proposed uh would have been to uh to call uh verification you would pass the root you would pass proof which is a a bite payload with uh that is opaque so the the pre-compiled itself itself would decide if this is an MPT proof because we're at an EP MPT height or if it's a veral proof because we're at a veral height or whatever kind of proof scheme we want to use in the future and then um have one key and one one value and verify that uh that this matches so the key would have been a 64

by value because we could potentially support um or at least extend the the key format in the future um so yeah prefix it with 12 zeros then 20 bytes of for the address then the slot number which is 32 bytes um and that would only be necessary to prove uh values so Storage storage slots now uh Jordy that's not what he had had in mind um I'm still having the conversation uh so I I didn't get to the to the end of the conversation before uh before we before this call but given the fact that this is not really what Jordy had in mind and it doesn't really look like a proving

precompile what he had in mind um the fact it's not not really interesting for optimism I think uh now is the time to do some uh deep soul searching can we find any Bridge or L2 or dap which for whom that would be interesting right now that doesn't come to mind so I suggest that we spend maybe the next week looking for this for who for a person that would be interested and if we cannot find anybody or we cannot find anybody with a clear very clear-cut and strong compelling use case we just abandon this for uh for Electra or sorry the the other one uh

prag um yeah so that's that's pretty much it for for this topic awesome thanks uh cool test night relaunch which I think it's also you again I uh yeah okay so I need to share my screen again I don't know why stopped um but yeah so the test relaunch uh okay so something is missing in this uh in this slide uh because we we just talked about using the updated version of 2935 with the with the 8 kilobyte buffer so that would be one change uh we would add the Explorer from

ignasio to to this to this test net because it's proven very useful to to debug I mean that was the that was the purpose but it serves that purpose so that's really really good um we currently identified I me say we but it's gender identified an issue with self-destruct at block 261 so before the relaunch I would like to at least get to the bottom of this issue I know a is planning to deploy their contracts on the test net so I would have to coordinate with them so that they relaunch uh so they try doing this on the new test net instead of the current one uh and there was another point uh there was another problem and

it's entirely my fault I did not uh I got mixed up with all the revision numbers and I did not rebase so uh to the right to the right revision so G was using the the old key format so not map to field but uh the the compression and uh that will be fixed in the new testet uh so yeah that's pretty much everything we want to change for the new relaunch I just would like to know if someone has any other desire for the new test net but baring this uh we should be good to go and we should do it this week because

it's blocking bisu and uh yeah there's not that many changes so it should be done fairly quickly cool last up on the agenda ignasio had a few thoughts on the black sorry block hash Corner case you want to share yes um so I think it was on Thursday or last week I was looking at some coding get and I realized that we weren't charging correctly the blog hash

gas and while fixing that I realized that uh there might be a corner case that we might might want to discuss what to do and it's the following so uh if you imagine a contract uh using the block hash op code asking for the hash of the previous block technically speaking the way that uh we are thinking of 2935 uh we are adding this block hash to witness at the kind of system level because we are kind of creating the history so this block hash is already

added to the witness so any contract in that block that use the blog hash asking for the hash of this previous blog technically speaking shouldn't be charged any gas for doing that because that uh um trick key is going to be added anyways because we are building the hash history so uh yeah have some kind of discussion a bit around this if we should like charge zero for this corner case of asking the block hash for the previous block or not and there might be yeah I know maybe

different opinions because I know uh this is kind of coupling like if we charge zero we are kind of coupling the gas cost of block has with 2935 um so maybe we don't want to do that and keep things simple and simply charge the the the gas as usual as any other older Blog has request um so yeah I just like wanted to surface this case and you know see if somebody else has strong opinions um I don't but uh if we decide to do something special we should add this uh

clarification to 4762 because it would be like um something to clarify yeah just like software saying topic just to specify one thing it wouldn't be zero right it would be 100 like it would be the warm cost of floing the the contract hash yeah yeah I mean like witness costs yeah is anybody like in favor of not of doing this kind of gas optimization of not charging the witness addition for

the previous block hash okay looks like the answer is no so we won't uh can you repeat this right so um to give like a tldr of what I said is uh if a if a contra is executing the block hash instruction asking for the hash of the previous block technically speaking that uh witness addition will be done Anyway by the chain because we are building this blash history in 2935 so technically speaking we could

charge this contract zero of witness cost because this Branch uh will be added anyways to the witness so uh like contrast could assume that always the previous block hash will be in the witness so you are getting this for freeing quotes regarding witness costs uh already not charging witness cost for Block hash right but that that that sounds like wrong right not essentially in the sense that for example if block hash I think I also wrote this up in the pr to the pr uh

which might be merged as well so basically uh what I essentially wrote was that uh when could the clients could just keep 256 or maybe you know when we go 2 81 96 whatever yeah so those in the memory and can serve from there so basically uh client architecture if I see as a full client running they can just keep on uh maintaining this in the memory as they do maybe currently right now and I actually don't feel that you know there should be any extra excess cost for block has because uh this is something that we can make sure that we can keep Low

by maintaining it in the memory or if we don't maintain it in the memory then still I don't feel that you know we should charge extra for Block hash that way uh that way you know the contracts which are already deployed so will be Backward Compatible to that if they are resuming any sort of cost for this particular op Cod okay so this is like a a special case in which there are something that is increasing the witness size and isn't really Charing for that that's kind of an exception to the main rule let's say yeah I think I mentioned this in the EIP uh PR as well and sort of was uh was

sort of uh you know under the impression that you know we all are on the same page with regard to that but yeah can we others can also weigh and on this particular issue but I think that we don't need we shouldn't be charging extra for the block hash because it just it could just be served out of memory my question is and I was my counter do we really need this because who's going to be willing to use block cash for the last block that was produced like is there really a use case for this I uh I don't see it typically

people generating proofs are way too late for for the next uh for the next well to to ask for the block has for the previous uh of the previous block um if if there is a use case I'm happy to change my mind uh but currently I think it's a very Corner case is uh very very specific use case that no one really needs and it might make things a bit weird uh for whoever doesn't know the EIP by heart and and does not understand that but at the same time it's the my counter the counter to my counter is already included uh if this is not a problem that uh will really ever

occur um then they will never notice that there's something a bit off um yeah I don't think it's really hard to do I just wonder if it's really worth complexity so just to mention that we don't charge for Block H block hash access even if it's more it's uh previous than the ancestor so basically any of the block block hash acccess we don't charge um yes okay maybe I misunderstand what you mean but we at least charge the the

warm cost which cost I think we only charge whatever is a up code cost for the block cash and we don't really charge an access although we create the access I'll get back to you offline because I need to double check the code but I'm pretty sure uh we do something called a check account and so that will return our account check and that would return a warm cost but okay I'll get back to you offline in like 10 minutes cool okay uh I guess before we wrap things up there were a couple of questions from Milos in the Discord I

was wondering maybe we could quickly answer around how to get a veral proof for a block from the testnet if anyone uh more familiar with um yeah we I mean just think that's the the easiest the easiest way we could tweak the Explorer maybe ignasio to to provide the proof because presumably we we look at those proof so we could save them and and provide them what do you think um yeah I was thinking maybe in the in the near future to also um show some like blog

information so we can yeah maybe allow downloading the the witness bites and also show like the witness size and other things that might be interesting so yeah we could add it there it depends what his U what Milos who I think left is interested in checking because uh Dora or who unfortunately is current down Dora offers some insight into the the witness itself so if that's all you need it's already present on Dora uh otherwise uh yeah we would need to explicitly provide some uh some way to to display or

download the the witness from any of the Explorers yeah I was mostly uh just thinking about being able to process and analyze that data Maybe by myself or something that is one use case and another question that was also on Discord is is it possible to to run a stateless client at the moment and how just instructions or something um that would be question for gender and U and or tennish but guess is not able to do uh so what exactly do you want to know

Midas is it just possible to run up any of the client in a stateless mode um and the instruction of how to set it up and get it running yes so reach out to me I can maybe help you run ethereum DS okay thanks and actually could you also export because you will download them this way would you be able to export the the wi es like the Json payload yes we we basically uh so etherum GS has a test spec uh script where basically it pulls off the Json payload and then plays it

so what you're you're saying can happen like that if you want to play some particular block or some particular set of blocks um and eum JS can also in the manner that uh it can basically serly get the blocks and execute them like a normal client would all right I think that was it for today if nothing else we can end there thank you very much everybody anything

else oh sorry anything else and um and and I have a question I have a question that and currently uh um I'm because I'm new to this group and the first time first time I come to the come to the meeting so and I um now I'm exploring the the further optimize optimization Solutions and to and to make use of the ReUse of the proof that means that and if if the um veral proof of um of a recent visit or of a story slot of the siblings or the St of the story l or or there's or there's um a recent update to one

of other sles SL then I think that the veral proof to prove that recent um uh event could be reused again to to to reduce that and to reduce the proof size and ver time cost and now I have this idea and I hope to and do some research on it and to to to find if there's more um is have more space to to to reduce the gas cost for the for the V proof what do you what do you think about that and um but but I think that

because because of the time of meeting I think that we can discuss it um after the meeting and I I direct you yeah that sounds good thanks for the quick thoughts since we're running low on time if anyone has anything uh any thoughts there otherwise we can maybe take it offline or async in in the Discord okay I mean all I want to say is uh okay we we received your present your document we need some time to review it uh the first outline seemed like it's something that cannot be possible but if uh if if this is indeed correct we're

really happy to to to hear about it uh but we we'll get back to you when we have read the document and uh we can set up a call okay great thanks what mean yeah of course thanks for joining uh thank you everybody and we'll see you in two weeks okay see you next time thanks bye see yeah bye