Verkle Implementers Call #24

Transcript

all righty welcome to veral implementor call 24 issue 1149 in the PM repo on the agenda today we have six items team updates number two de net Readiness check three binary and veral discussion then uh discussing deletions in veral uh someone ra hand uh number five Petra impact and last if we have time discussion on veral sync and potential spec change to add a hash of the proof to the El block header cool that's the agenda we can start off with anyone who has updates

client teens or testing I can go for Basu um so uh we've been working on a uh a stem based flat database and we have a a working implementation of that it it looks like it's going to be uh a simplifying factor for sync for us and also there there's potentially some performance difference in terms of uh having to generate the stem in order to do uh SL load and so forth but um kareim is is hopeful that it's going to be not only simplified but there won't be a

performance impact kind of we'll simplify our flat database implementation um uh L has been working on the the gas cost and witness changes in 4762 in the update and I think he's making good Headway with that I believe he found um what he thought was an issue uh and it sounds like it's an issue where we're charging access witness for um for a code uh code access witness cost on a simple gas transfer so seems like we might have um at least maybe a spec problem or maybe that's an intentional thing probably wanted to discuss that I think he's trying to get on the call now actually uh but yeah that's the status

update for basally right now we uh have some some veral uh transition work that's been stalled for about a week or so but we're going to be getting back on that shortly uh yeah I'd be quite interested in the performance actually because this is a yeah so I'll give an update uh last week I was with the guest team trying to uh merge some more stuff into gu so there's been some progress in that and uh we discussed the sync as well and it seems that yeah we would like to figure out how performant it is to compute all the all the leaves in uh as as they are needed um so reading as loads but also

just uh building a snap shot that is based on on those leaves so yeah I'd be interested in your performance like if you have benchmarks because we have to do the same thing uh yeah otherwise um ignasio has done a lot of work on the testing framework we found a few bugs um and yeah probably 10ish is going to talk about this but uh we also found an issue in the spec so there's a spec update that we need to discuss during this call hopefully it's it's only a five minute thing and uh otherwise yeah basically uh implementing

costs like naota cost they seem to be more less ready as far as we're concerned so we we would be pretty much ready to launch we still the for a new test net we still have maybe two or three issues but they can they should be able to be fixed this week um and so yeah I think that's it Ino you got something else to add no that's a fair summary I can go for ethereum JS uh we have made some uh further work to prepare for the eventual uh cin update we are going to work on

running the actual tests this week in parallel to this we've also made some upgrade to rust uh cryptography wasm while the the like JavaScript wrappers around that so that we can begin creating proofs ourselves so this paves the way for a stateful uh virgal State manager whereas before we've only run blocks stateless uh I can give an update for NE mind so we mostly working on like getting the hi T hi test running in NE M he found a few bugs and I think they're fixed now and except for that as G

mentioned there is one change in the uh spec uh on like how we charge gas for call and we continue working on the transition like the refactor is almost done so once that's merged we like start implementing the transition part apart from that uh yeah we working on some cryptography improvements as well I just wanted to uh clarify something about the tests uh mostly for Gabrielle that mentioned that he's planning to run them so in the next I would say like one or two days I will release a new version of the field fixtures uh because I'm now that witness assertions are working um I'm finding

that some tests require some exess so yeah maybe like you want to hold a bit until I publish this new version so you don't waste time by debugging test that might be wrong um yeah I can go for Aragon next uh I've been working on integrating the gas cost changes and the witness calculation changes uh so writing dirty code I have been successfully able to complete it uh noticed some issues with uh the State Management in Aron with regards to uh

veral tree I don't know maybe something uh got messed up but I'm hopeful I'll be able to resolve it in this week uh so for seems like uh arone might be able to sing to the tip uh for uh devet 6 so I'll have to make some little bit of changes for the next devet uh and then I might uh start working on passing all the tests um we uh in Aragon 3 have already started uh fully committing to migrating everything to arigon 3 which is our uh next version with a different model of t uh State and everything my

current implementation is based St on um the Aron 2 which is an older version of it uh although all of my changes are on uh top of Cancun uh not chappella oh sorry not Shanghai something uh which means that I'm trying to focus on writing um write the whole thing in a way that I don't have to rebase again um so that has been working out for me uh but moving forward I think uh I would um abandon this line of code and then start working on the Aragon 3

version of the whole thing uh but before that I would uh try finishing off the rest of the work and try joining the next uh devet devet 7 uh hopefully uh soon after after it launches or before it launches uh trying to get it ready uh quick question did you solve the issue with the fork ID because I realized I I dropped the ball on this no I didn't I hardcoded it uh so it seems like why the issue might be may have something to do with some other flies difference in how the Genesis file

is treated uh didn't want to spend a lot of time on that because the folk ID calculation logic is rather simple and straightforward uh at best it might be a misunderstanding on my end so I've just kept it open for now surprisingly enough when I tried to uh use get uh it did give me the wrong folk ID the same as uh Aragon's folk ID for some some reason uh but I abandoned the investigation there because I thought I'd be able to resolve it later yeah that makes sense cool I can go for lot which is not

really testet related but I have been trying to refresh uh the branch uh reased on the latest uh code that is there in LSA which should provide a more St base to run the test night on because of the improved performance in the L latest uh lotar code base so right which makes me think uh if we are to relaunch the test net we need Lighthouse I mean lotar supports the new proof format uh Lighthouse most probably doesn't and I think we have teu also is

anybody from teu here I guess not so we'll have to ask to find out who's working uh on this for teu because there used to be Gabriel Fukushima but I think he moved on to somewhere else um yeah uh I just wanted to uh bring something up from Bess um Gary already talked about the gas cost so I'm working on the gas cost and I've found out that uh we were still using the old key um design of having separate balance nons and and whatever and uh so I'm I've did some refactoring

on the on the veral TR library to uh to now comp uh compound all of these into the basic data LIF uh so that kind of drag me down a little bit on on the on the gas cost s uh but I'm finished that to factoring and um fixing or or setting the gas cost right I think it to be more straightforward from now on uh I did found something on the spec about U simple transactions I've discussed that in the in the Matrix chat um then ignasio replied there um about simple

transactions uh where we also touch the code hush uh key uh on the on the origin uh account uh that was looked a bit odd to me but you you clarified that it's mostly for uh code simplification so that's it sorry for joining late so I completely misgar a bit thanks for adding that bit of color I knew there was something but I wasn't sure cool I think we got everybody did I

miss anyone or did we miss anyone I can give a quick uh couple minute overview from the testing site so as ignasio mentioned um we have the witness asss now within the framework when filling tests so um essentially how the framework Works currently we have postate checks so essentially you write a test and you assert that a balance is what you expect or um some storage value is what you expect in the test and it's more of a sanity check and to make sure that the test that you have written is uh doing what you expect so it's essentially that but um for witness

specific values um so yeah ignu had kind of wrote a an API um for this and now we have this um within the framework now um and with the witness checks we have essentially essentially a runtime issue I guess with the transition tool it's not it's not really a huge deal and it's very resolvable um so with with uh filling the tests in East we have um or we're using G for a lot of the vertical calculations that we can't do um in Python natively which means calling g a

bunch of times at least the way the framework is written right now um but I guess the next step in our side is to optimize how we F the test so instead of calling G maybe on average 10 times we can just do a single call to G and it will um essentially improve the transition tool run time so yeah on our side we'll just be optimizing optimizing that cool okay moving on then agenda item number two devet Readiness uh I

think we already understand where everybody is here maybe we don't need to spend much time does anyone have anything they want to add here no gomu flag that you might want to touch on this but yeah um there's actually a couple specs that are still open uh sorry updates to the spec that are still open let me try to find them um maybe just quickly go over them and uh we don't have to spend like a long time just uh figuring out what they are but um yeah like should we support them for the test net or not uh it's three eips the first one is an uh uh unconditional uh account right during contract in it in fact uh yeah this one

is the one that was reported uh it was an error uh found by tanishk and uh the idea is that we uh yeah we instead of um when we initialize the contract we've write everything and this is because uh there can be a case where you run out of gas before deploying the code like while deploying the code but uh you uh like you know so the contract should not be created but the account itself is created before so uh what we do is we simply instead of making being dependent on the on the yeah on many events that are a bit uh

too complicated we just say every time you create uh a contract like when a contract creation is initialized you uh at any time you create the basic data Leaf key and you also create the code hash Leaf key um it's covered by the 20 I keep forgetting the the amount of guas that represents but uh the 24,000 gas um so I think it's only fair to to to since this is only fair that it should be covered by by this uh upfront cause that you have for the contract creation but on top of that uh it's also simplifying because you don't want to find yourself

stradling ac across u a lot of use cases where the data Leaf is created but the code hash is not so just to be completely fair and completely uh like to simplify the the code I think we should just touch everything at the same time and be done with it so this is what this uh this update to the EIP is um if you're okay with that we can merge it I mean I don't expect uh everybody to to give me an answer on the spot but please have a look um it's EIP yep there's a hand being raised um okay if someone raised their hands I

didn't see it um but yeah so that would be that would be uh just a simplification so just tell me what you think and then we merge it and we have this for the test net because I think it's a big simplification um the next one is by gender I'm trying to yeah it's just an a clarification for the system contract update I don't think it's a big one uh I think we addressed everything so also have a look at this one like yeah I'd like to get everything merge this week so please have a look and tell us uh if you don't want us to merge it because we would like to merge it this week and the

last one yes so the last one is simply well it's not really necessary for this test actually yes it is um it's all about saying like we we had this discussion in Kenya uh um 2935 so State expiry sorry not State expiry State history contract is uh creating is favoring evm execution and we're saying in this EIP that's true up until until a veral fork and when we get there we no longer favor um system contract execution but instead we we favor direct updates to the state now if you still want to do contract execution that's totally up to you but you have to

filter the the leaves because we don't sorry the the code trunks because we don't want the code trunks to end up in the in the State uh sorry in the witness um so yeah this one should also be merged ASAP so I can uh copy them in just a minute but that would be uh that would be the the three things we we would like to to merge before uh before we relaunch the test net on the spec front so that everybody can agree like there's no outstanding changes that some people implemented and others didn't yeah that's pretty much it for this topic sweet thank

you if no comments we can keep going cool uh next up we have uh number three binary and veral uh so I have a few thoughts that I wanted to to uh start off with and curious if what I'm going to say I don't know just overall makes sense to people if anyone has any thoughts comments questions obviously it's sort of a maybe not obvious but yeah I think it's becoming more and more of a sort of a Hot Topic uh which is this question of of uh binary versus veral and the viability of uh I guess ZK based stateless clients in something

like the next 3 to five years let's say uh and so yeah I just wanted to share my I guess my own personal viewpoint on it and see if it resonates with people or if people might disagree with how I'm sort of framing it in my own head um and so I guess yeah the way that I'd summarize it is uh clearly today veral is the most viable path to solving State growth and enabling stateless clients but you know that's today and of course we need to keep an eye on the future it's you know also quite clear that ZK Tech is advanced ing rapidly though how rapidly it's advancing and like what the trajectory is over the next 3 to five years will depend on who you ask and

reality is it's probably just pretty tough to predict the future um but yeah cannot argue that there's a lot of investment in that area of course and it wouldn't be a huge shock I don't think it would be a big surprise to anyone here if we continue to see massive advancements uh so yeah I guess the obvious question is like what do we do given this Dynamic this the sort of the the dynamic behind verl is most ready today but isn't shipping today uh and by the time we are ready to ship fle on mainnet it's you know at least possible that ZK stuff will be ready or close to ready and our goal of course is to find the solution that's the best solution for the sort of medium or

long-term health of the protocol um you know obviously we all have invested a lot of time energy into veral um and so we have some biases there but I think all of us would also agree that we want to find the best solution um so yeah so I guess given all that my perspective at least is that it makes sense for us to basically do two things one is invest some amount of bandwidth into exploring binary trees and of course this is something like for Gom Going Back to the Future he's he's done this quite a bit and perhaps others others here as well um uh so yeah what does that mean exactly investing more bandwidth into exploring binary trees I guess like that's where I'd love to get feedback um

more thoughts um but sort of at the very least making sure we understand um like what are the current benchmarks of ZK proving times how many hashes a second what are the metrics we want to be looking at what are those benchmarks on what Hardware lots of questions it's not necessarily super easy to answer uh and then keeping an eye on this progress uh over the next six months to determine the viability so that we get a more accurate sense where we are today and and where we are going and checking back on this um but yeah like beyond that I guess Beyond understanding benchmarks understanding sort of Hardware Hardware requirements um this kind of stuff I guess it's a bit

TBD like what does this mean to for us to invest some amount of bandwidth into exploring binary U and then so that's number one and then number two I think um I guess justess as important to the extent possible we try to plan some of our development uh in a way that is most tree agnostic and I've discussed the Su with Gom and Osio and you know like I guess I don't yet know exactly what that looks like or to the extent it's it's feasible um but just like as an example spending more time on the conversion actual State migration process since presumably as far as I understand it would look similar whether we are ating to Binary or veral um yeah but we would

love to know what people think of of all of this overall I think and I mentioned this to Gom is like like what we want to do is to keep our eyes open we don't want to um I think like that's how we get to the best solution and that's how we actually at the end of the day if we arrive at the conclusion that verle is the best solution um we want to have arrived there through like of course like a transparent and like honest process and like that will allow us to have our endorsement or our recommendation be the most um what's the word I'm looking for like most um yeah valid if we we got there through like an actual evaluation process um so yeah

sorry if that was kind of a lot but just wanted to like I guess in my own head like there's just been lots of conversations around this and I would love if we don't I think it's less productive if we spend the time debating this like binaries better no vertical better and just kind of going back and forth and more so like let's try to look at this what are the metrics we need to what are the metrics that we're looking at and you know what like we're going to move forward in a in a more tree agnostic way at least over the next six months let's say so we don't have to get bogged down in this debate every month anyways so so that's my my thoughts and we'll be curious if anyone has anything uh just to add something quickly we would like to update recorder

info to we're going to add a a page regarding this so that people can track where where we at in our reflection and of course contribute to it if they they have something to say which uh you know we're no ZK expert there's plenty there's plenty of room for for other people to to give their input um so we'll be sharing it hopefully by the end of this week there's there's document that was in the pipe that needs to be refreshed but yeah I I hope we can do that by the end of the week yep that sounds good just to add one bit I would say that U you know designing in a tree agnostic way and uh um I I think in

addition to that like leaving room for a fast follow is probably wise because uh even if we determine that uh there is a by the time we're ready to deliver a vericle there's there's a a path forward that is defensible and and future proof it's going to be add another X number of months or Worse to to the delivery so what I would say is um in design consideration and in Spec consideration we should uh keep in mind a fast follow like things like keeping around a uh a pre-image store should be an expectation for veral like if we we intend to go veral but we know that there's something that might want to follow that would be more future proof um just kind of setting the setting the stage that we

might be uh doing this transition one more time so so we don't want to have the pain of doing you know pre-image store distribution and so forth again so I can just just setting that expectation I think would would uh would help with uh you know a subsequent fast follow yeah that makes I think that's a good point it's hard to predict I guess if we will end up doing a fast follow or not like let's say we do ship verle what are the odds that we do have fast follow uh but yet to your point we can avoid a lot of pain if we just plan as we we assume as if we are doing a fast follow um if if I understood correctly and that makes sense um that that makes sense to me um yeah I guess one thought is that if it becomes obvious that a fast

follow or or likely that that we'll have a fast follow then I think the basically we'll get a lot of push back people say nobody wants to do that nobody wants to migrations like let's just go right to ZK or sorry to Binary but yeah that that will be something that will yeah and fast is a relative term too right I mean a fast fork follow might be you know 18 months two years who knows what that would be but I I think just setting the expectation that we need to leave the door open for being able to do this transition less painlessly on a subsequent iteration yep makes sense and just to add to this the initial road map I mean this is something I've said multiple times but just just to make sure it's known um we like from the initial version of the of

the road map was always like we would do veral for a while and then binary trees so there was always uh we always kept in mind that the next the next uh process should always be faster and at least simpler yep I think yeah it's a good reminder and we should continue to articulate that yeah and I just want to um sorry touch a bit more on the point of doing um state three agnostic progress and all that I think that we have naturally reached a point

where that is true because I think mostly everybody already has aultry implementation and most of the work that we were planning to do now was around State conversion and 95% or even 100 % of that EIP is agnostic to the Target Tre um and also all this this spending discussion about pre-image distribution is basically the same problem for bural or for binary trees because pre-images are for the Marco patri tree so all that thing is mostly the same so um I think that most of the pending work is actually own stuff that is Tri agnostic so that's pretty useful

too um maybe the part that is less agnostic is um witness Generations or cryptography optimizations for bural um so maybe we can hold a bit there um but yeah um 4762 is mostly the same um State conversion is mostly the same and pretty much distribution is basically the same y makes sense any other thoughts do people generally agree with I don't know the

what we've said so far my framing of things anything I said dis disagree or not make sense uh one thing to add is we're talking about renaming this uh the stateless implementers call maybe instead instead of the veral implementers call to to signal that we're looking into stuff uh that veral is still the the Main Avenue but yeah we're we're not closing the we're not shutting the door any objections to the rename from Vic to sick if no then I guess we'll uh we'll

move forward with the Rebrand SI um yeah maybe we can uh relight some excitement I think we've maybe uh maybe we lost the W people over the past few weeks not to pick on them but maybe we can get them back okay um moving on then uh number four discuss deletions in veral new oh yeah so this is not something I'm I'm pushing for it's something that um that uh Peter and Gary especially in the

guest team are pushing for uh their fear is that the fact we we have no deletions is going to blo the state so I'm currently working on optimizing uh the storage cost sorry the storage um like the serialization of the veral tree in the gas database to prove well to make a point uh which can go either way either they're right and uh never deleting anything is going to bloat the state in which case we should definitely consider deletion um otherwise if it shows that it's um that it's well that it's not a big problem then I guess that's enough

for me to push back uh against this uh this desire so at the core there yeah there are two reasons one of them I think is not I mean in my view should not be the problem of uh of the tree design it's the fact that gas really doesn't make any difference between something that's uh like like something that never existed or when a zero was written um I think it could be solved at the database layer problem which is what I'm working on to see if I can uh if I can make it work um but the other like the initial problem in the initial compain especially by Peter is that the the

state is going to be very bloated if we if we do this um so I'm not uh saying we're changing the spec right now I'm just saying like this is uh something that this is some strong push back that I received last week uh we might have to argument either way and um yeah maybe if people have questions about why we need this uh I'd be happy to answer them but otherwise uh yeah are people for deletion like introducing deltion are people strongly against it there's a very good reason to be against it it's to handle uh the conversion because then

you need to somehow flag that something was deleted from the veral tree and you should not go into the the the merot tree um so that's that's a complex that's a complexity that uh yeah that needs to be worked on um so that's my my reason not to do it U I'm just curious if people have an opinion or if you know they would like really like to do it if they don't want to do it etc etc looks like no strong opinions is there

is there room for there for there to be a trans transition specific deletion Behavior yes um so that's exactly what they were suggesting and uh I have to implement now um You would have so at least in the the guest code base we have Three Trees uh we have like the Merle tree we have the veral tree and then we have this adapter tree which is not really a tree it's just uh doing the yeah like dispatching all the requests so the writes and the reads and this layer would be the one saving to the database where uh where uh something got deleted so that when you read it again it would

it will skip the MPT all together um so there's a way to do this it hasn't been implemented yet so I I don't know how much of a yeah how complex that approach is um I fear that might be a bit complex but if it works then I guess that's uh another good reason to to have deletions uh yeah no like there's an idea no concrete code yet [Music] okay if nothing else on this topic we

can keep going agenda it sorry sorry uh I saw a message uh didn't see who that was but to talk to about St par oh yeah get Ginder um yeah so that's the other thing about because the other argument is that not deleting helps with State expiry like Han uh created this uh EIP um to or at least came up with this idea to to have a state expiry based on this this whole stateless model uh which is really good in my opinion but then if you introduce deletion you could not do yeah you could not do that um there like

the response by Peter and Gary which is also completely fair is that it's only a problem once you activate State expiry so the idea would be to enable deletions up until the point we have state expiry and then disable deletions and have state expiry but we then don't need deletions if we have straight expiry exactly so that's when you disable them uh like up until you get to that point the state is uh the state growth is a problem so deletions exist but once you have state expiry you have a better or at least simpler approach to

to handle your state growth so you disable deletion and you enable State expiry and in fact you need to disable deletions because otherwise they expiry like this model is broken maybe we go live with State expiry um yeah we could do this but that means it's going to imply more coding so I expect um ACD to to push back on this oh uh yeah I see a message by ignasio

yes it will uh increase it will blow to the code size sorry the witness size a little bit but we uh yeah we would be I think if deletions don't happen that often it's uh it's just about creating a list of locations that get deleted so there will be a bit of bloat but we believe we can make an efficient enough way of uh of yeah updating the the witness format to handle that cool I guess we should keep going stay

on time uh yeah so then if that's all good next up is number five um evaluating the Petra impact of a few things in particular those being 7702 and eof uh and a few others but um ignasio or does anyone else want to start here um yeah I can mention that in the last days I've been reading in more detail the uh eof eips uh to understand how like the new container and instructions my impact um um like thep so I basically went

through all that um and created a draft PR with the changes that I think are required so I will share that in the chat um so I mean there's no rush for people to review this but uh if anyone um uh UF eips in their mind uh I want to kind of check if this makes sense um that's welcome um nothing about these changes should feel entirely surprising uh feels like uh natural changes overall uh considering uh all the new instructions

that exist and um some extra touching that we need to do in the container header and other section in some instructions but um if you find anything surprising or anything missing just feel free to create a comment there or pick me so yeah that's basically it uh right and I did have some notes uh because Matt from the guest team explained to me uh what 7702 entailed so there's a

yeah there's an issue on the go ethereum like in my repo go ethereum uh U issues that explains that U what 7702 does um there's a couple like I I mean compared to EF at least 7702 looks pretty simple it's just about making sure like I'm giving you the the 5c summary uh you can have contracts that or sorry accounts that delegate their um yeah their um I don't know how to say that but basically when you do an operation on an account it's a delegation that goes to another account uh it's encoded by uh some field which is ZX ef01 so EF is ZX

ef0 and0 ef01 is followed by an address that this contract delegates to so that should be a contract with a code so it's just about simply making sure that when you add something to the witness you add the delegate the the contract that uh the operation is delegated to instead of the of the account itself otherwise the the witness will be empty uh so it does blo the witness a little bit but yeah once again it's not uh I mean you're paying for this so um 7702 is going to be a tad more expensive than it was but that's also the case with eof anyway um so yeah that's pretty much it if there are

questions I'm happy to answer them but that was more like a heads up cool if nothing else shall we move on last up and final sorry someone say something no I just answer your question yes we can move on yeah cool thanks uh last up the uh Burl snc and potentially related or included in this bucket is a

to the EO blocker um yeah sorry I'm confused uh what is uh what is the SPC change uh I didn't uh I didn't expect that yeah I guess we already touch sorry yeah now I remember yes of course um so yeah once again uh we discussed with the guest team last week how to make uh go eum be able to snap sync or veral syn so there's already a model proposed by Tanish which is pretty much what we agreed on um a couple things were suggested by Peter one of them is uh currently we don't add anything related

to the proof to the to the blog header uh Peter wanted to be a bit more strict about witness validation so it would be that every even full nodes will have to validate Witnesses and make sure that no uh no extra data is being passed um like as a way to prevent people from bloating the the witness with with things that are indeed uh correct but are not necessary so what Peter would like to do is basically flag a block that has too many uh leaves as as invalid even though it's correct in every other

respect um and the other thing would be to uh because of course if we do it like currently uh the witness is is a side car currently I mean witness and proof if uh we start introducing this rule then we have to make the witness itself part of the block because if I'm a dishonest host uh sorry a dishonest node I would receive the the honest block and then replace the proof with a bloated one to get the block uh declared as invalid when in fact the the producer was honest so that means that we would have to produce the proof in the blog

building cycle and we would hash this proof and add it to the header so that was one request uh the other thing that Peter wanted um yeah so have a have a snapshot that is uh that is per stem and not by the hash like the traditional hash of like it currently is so basically have a have a vertical specific snapshot but I think that's already what uh what Tanish is doing um there was another thing I'm forgetting uh I mean okay these are the two main uh the two main changes I think uh yeah there was

another detail but it discc me now so um yeah at some point we were talking about oh sorry yes there's another detail um currently we pass the preate and the postate the the post values um that was meant as a way to make it easier for yeah very very like notes to who don't want to to run the block to somehow trust that the data they've been given is correct uh it takes roughly like it roughly doubles the size of the witness so yeah Peter was uh especially but other members gave some push back I never lik this idea to begin with

I uh yeah so my question was more like those who have thought about the the syn uh I already astonished this but maybe there are others others who were counting on those post values uh we would be removing them if if everybody is okay okay so I still have to yeah to ask danr if he if he's okay with that but I think there's a good agreement that it's taking space and uh and not um not being really useful at least uh I mean like

Martin was saying there's uh there's very light uh very light like VMS today so you could totally execute a block even in in a light client that's not that's not a problem um another thing that es skips me again that I was just thinking oh yeah it's the duration how long you need to save the witness um on your dis right so that's the that's the other important thing uh because you hash okay so there are two things about this hash uh you need to re like when you build a block you need to rebuild a witness to be able to Hash it or uh Peter was saying after while like if the block is old enough has enough confirmations you could say

you only verify the block until you know like a month ago and before that sorry you verify the witness uh otherwise you just trust the hash because yeah if it was a month ago presumably you're on the right chain and um the other thing he was saying is yeah we need to keep the witness however because he wants to be able to so his use case is that he says when you sync you have to trust the network so but and and then it's a manual very apption so it's up to you to verify that you have synced the right um the right chain so that's a manual process like he says sync is a manual

process but there's the use case where you go on holiday for like two weeks your node dies day one as it tends to do um and then excuse me and then you need to be able to replay every single block uh to catch up by replaying every block and for this you need the the witnesses like if you're State less client you need to be able to download the witnesses so what Peter wants to do is keep the Witnesses on dis uh for a certain period of time to yeah to be able to what he calls um a headless uh to do a perform a headless sync uh like or automated in a way that unlike the

the initial sync where you you are here and you verify that you're on the right chain if you have a power cut or an cut and you come back online you have to make sure that uh sorry you don't have to make sure the node has to be able to recover by itself without you uh yeah watching it or manually U doing that verification so that's the argument uh that means we're not saving as much space as we could but uh yeah we we would keep the witnesses for one month which I I calculated uh if you keep the post the post uh value would add an extra 60 gbt which is not light

um but yeah that's basically the ideas the that we discussed uh last week so I don't know if there's feedback questions or if everybody uh seems to be fine with that uh but I mean yeah so keeping the witnesses that would be a GU a GU thing uh everybody's welcome to do the same thing of course but yeah that's what guest would do and yeah if there questions or push back or feedback I'm interested would wouldn't keeping block Witnesses back just to the latest

finalized block be sufficient do we really need to keep a rolling month is there a reason to keep him Beyond last finalized yes um I mean there's a reason I I mean I'm not convinced but Peter is is really insisting on this um the reason is that yes your if your node you know crashes for example and you're gone on a two week three week holiday you come back you definitely pass finalization and you need to be able to rejoin the network um automatically so without that the the cut off of one month is that typically everybody's holiday is less than a month so that that's why

um like I said you're you're welcome not to do this if you don't want to you you can keep it two weeks you can keep it all the way to finalization but that's the reasoning behind it why we want to keep so much so portal network is definitely a plan for that and in fact Peter said yeah that would be a perfect use case for portal network but my understanding is that and Milos is here uh my understanding was portal the portal people themselves were thinking that was not a good use case um I'm not sure I think it might be a a use case to to keep witness

there um together with many other stuff that are on the portal network but it was never kind of discussed in details but I would say it would it makes sense yeah so that would be a super great use case in that yeah that would be a great option all right well we are just about at time

there's nothing else in the last minute or so we can end there cool all right thanks everybody to you bye thanks everyone bye