Verkle Implementers Call #2

Transcript

foreign ERS call number two we have a few things on the agenda today so we can just jump right in uh Liam do you want to kick things off uh uh yeah sure work I did on overlay I was going to share my screen briefly um here we go uh right so I updated um I updated the like the document created

by Perry about the transition to start giving some some Benchmark related to the overlay there's still like um tentative but it looks like on the Fairly modern but not so modern machine like a ryzen 7 so it starts uh yeah it's a few years old actually I'm not quite sure how old it is but it's definitely not latest generation um I tried to convert 1000 nodes per block and 10K so the estimate is that with 1000 node per block sorry 1000 Leaf per block it would take about five months and it takes on average 15

milliseconds to to do the turn the conversion so um for 1000 uh nodes sorry one thousand leave and the worst case I've seen were 30 milliseconds but it really didn't happen often so that's a good basis of course it it lasts about five months but um yeah I'm I'm of the opinion this is acceptable I'm interested in in hearing some some feedback about this I also tried 10K which would be the uh like the the worst case uh that I'm like yeah the worst I'm going to I'm willing to go uh per block and it's still 120 milliseconds on average uh so it tends

to even out when you when you start insert inserting more keys uh per per block um that would take 15 days so I think that's uh 10K is still uh I'm not sure most of the network can can achieve that but uh 5K at least looks feasible I think I mean so I mean for based on these numbers I would definitely go for 10K and the reasoning is I feel like um don't can't we just do this conversion between slots like yes we don't have to add this to the block processing time but we do it before the next block is

processed completely yeah so we already have all the data so it basically doesn't add anything to like execution latency and so on it's just like something extra you have to do after you've verified the block right absolutely yeah so that's definitely an option um then I would rather um like have a bit more because that that is still quite a small number right that's like yeah like I mean establishing the the load per block okay fair but that would only matter while you're searching yeah so instead of after I would say before a Blog and then the block would go in because we also need to verify vertical root right so it's part right I'm clear I'm saying

like yes like like logically it would be before a block but that means like uh in terms of causality you do the work after you've just processed the block right so I process a block and I can immediately do the work for the next block that's what I'm saying because I know exactly like what's going to be the start of that block yeah yeah I'm just pointing out that it has details and census yes yeah it's still in consensus it's just logically at the start of the block so you can exactly predict what work you're gonna do yep nobody agreed that that would be the the optimization the question is still so what's missing from this uh from this Benchmark

um is what happens on the on a low power machine like like the Rog 5B which I think represents the the lowest machine we're willing to support the most underspected machine we're willing to support um so that's the question like can they still do 10K leaves within you know a reasonable time like uh let's say let's say six seconds add anything to Ram requirements sorry does this add anything to Ram requirement storage sorry memory memory requirements no it's really computation computing power yeah was this a test on my net database

yes okay very good um yeah so I think we should try to run it on rocks 5B um yeah yeah agreed uh I'm just I just ran a bit of time sorry I ran out of time to preparing for this but uh yes that's that's one of the goals okay and uh yeah so uh those numbers I to to run those numbers I replayed roughly 2 million blocks so I started a bit uh like before around blog to get those numbers around Block 14 uh 1400 um sorry 14 million but uh yeah so far I

uh there are still a couple bugs but you know we're playing two two million blocks gives me confidence that uh that this works well enough so yeah um I mean I'm willing to hear other people's opinion of course but in my in my view I think the overlay method is uh yeah is the way to go um yeah and so that was pretty much it for my uh for my updates um so this still I mean what what what they're still uh can can we can we clear storage while uh

while we're doing this so like would you be able to clear the storage used by the MPT at the same time not exactly at the same time because we need to re-uh roughly yes within like a day or something exactly so that's the point well the first thing you can do as soon as the transition start has passed finalization is delete all the internal internal nodes of the tree right you all you need is the is the leaves like most clients are at least I'm saying mostly I'm not sure actually but Geth and bisou and presumably arrogant at least uh have uh have a flat database I'm not sure if you guys have rolled out paprika yet uh do you no no no no no

it's still development but I think it will be before vertical three is definitely right so in that case if you have the flat database if every client has the flat database um yeah like storing its data it's Leaf data into a flat database you can already start with deleting the entirety of the of the internal nodes and then uh because it's predictable what gets deleted uh what gets converted from the MPT inside the vertical tree you can start deleting those like you said with uh with a bit of a buffer so that you you are able to reorg it but yeah the you would be able to to delete the data my prototype does not have that yet but

that's really not difficult to implement okay for the decision part I think obviously it does not matter in the protocol but we should have a kind of a soft offset on when we start deleting the data so that we don't and like happen to be in a case where the transition went wrong and

client does not have the initial More Country That would be a huge problem I guess so I think we can probably do something like wait for a day or two and then he started in the internal nodes or the uh converted data yeah that's uh I mean at least that's that's how I understand it I was just going to say let's wait for the finalization point but we can be even more uh cautious by waiting a couple days for sure there's a question in the chat from

Kareem yeah when we will have a consensus regarding the transition mode overlay or something else okay let me see your thoughts I mean yes I have thoughts is when you agree this is the way to go and every other client agrees this is the way to go um no thanks I mean to be fair I mean just put up some document I mean the issue is of course that um the overlay method or transaction transition actually has a bunch of minor it's more of a spectrum of methods which can fit actually multiple things but fairly certainly will end up with some way of some overlay ish thing

yeah I would say like based on this currently I would uh just like say commit to doing the overlay until we find something that's uh some unsurmountable hurdles and then we can think again but I think like it's best to just try to push one method and uh yeah give everyone's uncertainty about that okay maybe that's a good segue for agenda item number two gotford you put together some notes on the transition

yeah I mean I just wanted to collect some kind of thoughts that I had I mean I'm not sure whether you all have the um a link maybe you can share some link I just shared it in the chat just put together some some notes because um my bit of an issue I have with this kind of overlay three method is that there is some kind of details that are not very terribly well specified or based in the resources I could find and pretty much everybody has some kind of idea of what overlay three means but um it's probably good idea if you all agree on what this actually means and while thinking about this I thought about sort of more of a generalized overlay um stream

um or method for the transition um this is not I mean put some document you can maybe go over it and read it it has some kind of alternative ideas about how to do things or some kind of Alternatives I don't think we should I think we should basically push forward a certain more Narrow Path but it's good to have some kind of Alternatives in mind with that maybe you can share my screen and just go through sort of some of the thoughts because it sort of affects stuff maybe you can do this can I do this Chrome tabs there's way too many Taps open you know this kind of problem um okay so maybe I can

yeah let me just shares on screen you can see this over oh well I think it works yeah um just to sort of make make sure what I understand was overlay method being for me this kind of overlaying method is just that at least during the transition time we have multiple trees and sort of some trees have precedence over others and when we sort of and then we somehow need to make sure that all the overall data which is currently a multi-partition tree ends up in some burglary and there is really multiple ways of doing this um like depending on how many increase you want to end up with maybe you want to end up with two work increases of go to some kind of um State expiry compatible setup you

could do this I think not it's not probably not but just to make sure that we can do this and there is uh two there's a bunch of points I want to sort of really focus on now which is they're assuming this is this document really asked a bunch of questions that we just need to sort of agree on I think for most we have kind of very clear Direction um one thing um this is something we need to sort of make sure it's the technically we want to freeze the Myrtle tree and um just one observation is technically we only need to freeze the Mercury keys not the values we could in principle have some version where we modify the values under the emergency provided they don't touch the keys themselves this sort of

om allows us a bit of a leeway the other thing is sort of really related to pre-image distribution mean um there was this kind of thing that we either you know there's an EIP now I think it's emp6873 which basically says that we should probably before the before we freeze the Mercury we should start recording at least the more recent pre-images the other option is I think I put it up last time that basically what we freeze the Mercury we wait for a certain amount of time until at least the um actual um point where we throw the tree has finalized and which gives us enough time to actually distribute the

total set of three images via some other channels um yeah I think it's why what the Yeah just to answer the chat and if the worker blobs carry the pre-images for their account slots it it touches and we only need that for the we only need the pre-images for those that we convert via sweeping because we really have three three ways to actually convert we have we convert everything that we touched as part of the execution layer but we also convert everything even stuff that is not touched by the execution layer and for the stuff that is actually done what YouTube reads or writes we already have the three images they are in the in the

blobs in the blocks um we only need that for this stuff that we actually don't touch and this can be quite a lot and it's kind of wasteful and I mean this is basically some fixed amount of data once we've Frozen them and the MPT just some flicks fixed amount of data that we really don't want to um waste log space to disseminate that seems kind of wasteful to do it like that hope this answers your question do you want one Tech so yeah so yeah um yeah in particular I mean particularly this means I would not do um because one big advantage of actually freezing this is that we don't have reorgs crossing the boundary between

miracle and vertical which might change the set of keys and then because we have to iterate over them everything gets super messy having this finalized I mean I'm not an implementer but I would expect that this makes every Implement of Life much easier so this is also why I would prefer that over um eip's um sorry over efe 6873 and would in fact not go with the znp for that reason um the only issue is of course if you want to have enough time to distribute this wire on a separate Channel we need much more time preferably even some time to um put here in some emergency release if needed which if you sort of have a time scale

of 15 days or the whole transition actually makes a big chunk out of this whole time personal value you want that or not it's more of a timing question no I have no particular opinion on that maybe you have okay what do you think about this there is some stuff that we will have to actually care about I mean one thing is that it's I think it's currently always assumed that whenever we read something um and we don't find it in the virtual tree then we look it up in the Myrtle tree if it's there we are actually also converted so we convert on read I'm not sure whether we should do that and this is a bit of an open question that I just want to put up it has pros and cons personally I'm leaning towards not doing

it because it makes it easier but yeah let me think about it the other thing is this is a bit of a contentious issue in theory um when we write data during the transition phase and there is a bit of a question I mean if we add a new key then of course it goes through the new burglary a vertical country that's completely clear but if we actually add something to a pre-existing key there's actually really two options you can either write to the verbal the new version or you can actually modify the pre-existing Mercury not sure what is actually the best here this is something you need to consider and how it interacts with the sweeping there's a bunch of questions like when

you do this kind of when you iterate over all your old Myrtle Keys you have to make sure that yeah if I actually convert something that may have been converted already due to some of due to some right operation you actually have to take that into account and this also affects some question yes uh yes sorry I wanted to initially answer everything in bulk but at the same time there's a lot of questions being dropped so I'd like to uh to address this one uh the problem is not converting on read uh sorry being able to to update the the miracle tree um you know like just doing the sweeping and updating the Merkel tree still means uh you still need to have two uh two Merkel routes well you need to have one

Miracle root and one vertical root in the block so you need to change the block format uh it's a bit of a pain at least uh to implement this and get well okay I guess you could put the the root at the end yeah you could do this but it effectively reserves a uh a field in uh in the block header that will only be used for like 15 days or five months uh the other problem with this and it's actually the much bigger problem that means you still need to to have two concurrent snap sinks instead of having one because if you have a single like if the miracle tree is Frozen uh you just download the data and you're done uh and then you you vocals think like you you snap seeing the vocal tree if you still keep

updating the Merkel train um yeah you have to it gets more complicated basically yeah I mean I'm not in favor of actually writing to the vertical test let me let me be clear I just wanted to sort of write out a sort of an overview of the design um that within the overlay three method that's just the purpose of this just to be clear I'm in favor of not of basically keeping it frozen because it's each I've been in favor of the easiest thing where we can do it not squeezing out some minor efficiency gains here and there just not sure about the conversion on read I'm not sure what the problem is for the conversion on the read whether why would why this would complicate things you know um it's not well it's not complicated complex sorry

excuse me complicating things it's in fact making things a tad simpler but um the problem is always the the fact that I mean you know full well that uh Computing like if in order to check in the uh like if something is present in the tree you need to to pay the computation costs yes and um I would say might as well buy the bullet and do a the whole update at the same time yeah I mean so same saves computation that's clear it's just but at the same time it makes yeah it might make things a bit more complicated because you have when you do it actually all the sweeping conversion you have to make sure you have to basically take into account that some stuff has been converted due to other means but you

want that or not and then the other question I'm not sure what the current implementation does um the number of nodes that you actually convert I mean that's a bit of a question currently we have I mean I think I'm not sure what your experiments are you only doing sweeping or are you also doing something like concurrent reading rights how are you doing this no I mean not not concurrent for sure it's uh like they're sweeping So currently at the end of the block but it can be done before that's not a problem uh and then uh yeah and then the the execution of the block sorry a bit so big board the execution of the block that does auto conversion and then uh do the sweeping at the end 10K uh 10K blocks yeah I mean

that's just a question about this kind of timing issue is that in the principle if you sort of um are i o bound or whatever we could make the number of leaves that we basically convert depending on the amount of work that is currently done in the block if we follow downward suggestion that we sort of make some extra allotted time slot them which I would just go with just make a fixed number and do with it and if something has already been converted just get it but it's just something that we need to decide on something let's just the other thing and there's just one thing I I wanted to note it's never been I think it's never been mentioned before in principle it would be possible not suggesting we do it but

just makes it make clear that it's possible that we could actually have some kind of overlay three method that ends up with two with two vertical trees basically by saying Yeah we actually convert from some old pair of metal metal tree to a new virtual tree and at the same time we sweep from an old myrtle tree to a new purple tree they said what I think it's actually the easiest way to do it the downside is we end up with two trees and we don't want that just that's just all I want to say here um yeah just to make these things a bit more clean but I'm not quite sure and something that we need um

yeah okay um needs to care about a bit with this sweeping method is um that um how reorgs actually affects this kind of sweeping and how much I oh how much extra I owe you actually have to make have to care when you're doing a reorg when you reorg all of these transitions that you don't end up with some kind of some kind of completely bottlenecked by IO at some point in order that we lose finality for some time because we have a big reorg and all of our notes can't catch up with the extra i o from reorging all of these kind of transitions just to make sure that it doesn't have that's basically my main concern thanks uh yeah so for Io should not be a

problem because you have less notes to read um computation could be I mean yeah I would have to think about it but uh I think like intuitively I would say IO would not be the problem would not be worse than it currently is because you you need to load less stuff yeah I mean in principle it's a bit stupid from a certain point of view because once you if you sort of reorg into it it's another Branch you're actually converting the exact same leaves but still I mean you may have to redo all the work it would be nice if you can sort of avoid that so

um uh you don't need a miracle tree to actually do the conversion I think the only flat storage is needed so you can like Drop The Miracle tree uh like at the beginning of the conversion and keep only the Self Storage I wouldn't delete from the flat storage uh unless finalized Maybe just to keep the vehicle simpler so the flat storage is not kind of being reworked at all um and we can delete so only you can delete only the things you kind of sweeped right you kind of converted during these uh between block conversion let's say like that

and because this is like a linear progressing and in terms of reworks well it works on the vertical three would be like like normal rear sort of record three so it's just as any other on vertical tree so this is being covered so it's simpler so I would just gravitate to being this as simple as possible in any of those answers yeah same here just not sure about the conversion on the read Because this is kind of not too clear what this implies yeah I would I wouldn't do conversionally read just

it's simpler because you you'll all still like you have to go sweep through all the keys right so whatever right why do on the read when you will still get it on on the going through the keys it's like double doubling the work potentially um one thing that is uh actually a question mark here is pretty images right this is the least defined thing for me how to distribute it and I think it should be distributed through peer-to-peer through some kind of sync method but yeah that's an open question uh and this sync method should be deployed on mainnet it can be without a hard work right we don't need the hard work for

that because it's like adding a sub protocol but it should be deployed way before the transition starts like months or you mean the protocol or the actual pre images well before the uh before the transition starts the primages will change per block potentially right if we add a new account so they are not fixed they are not a fixed thing they are evolving thing so let's say someone starts thinking just before the transition starts he has to be able to think get the all the pre images

that that are up to this point in the time so I would say this has to be like and pretty much think protocol that uh the network would serve but that's my opinion [Music] um um sorry for me but in um there's uh so just just getting back to uh backtracking very briefly uh I actually in the in the Prototype I've wrote there actually are no conversions already so I I yeah I got confused but actually we don't do that so this is indeed the simpler version and this is uh this is what is currently being done

so those numbers are with no conversion on read uh getting back to the to the pre-mich problem indeed we can do uh we can distribute the pre-image either via the the peer-to-peer protocol or we can even do it via CDN that's what party was suggesting um the the thing is you only need the pre-images for the moment that the transit transition starts so uh there are several reasons why while the conversion would start um actually that's not true uh but uh yeah okay sorry I get confused um right you you would indeed uh need to to start passing the free images but the

enabling of the pre-image recording and uh just like what you need to to do conversions right um would be would be done uh yeah could be done without the protocol itself like every time you execute something you know the pretty much so you could save it and you could use it directly then there's indeed everything that was not accessed during that that period preparation period just before and that we need to distribute I don't really care how we do it as long as it works uh you said you were saying how big are the pre-images Enrico um it's currently at least for Geth it's currently 70 gigs but it's all the

primages uh some of which are not being used because they were used once in the past and never got accessed again or got deleted or something so it's it's probably smaller than that so um upside of doing it in peer-to-peer is that is self-contained right um it updates all the time and if you like um if you think whatever time you you have it if we think it's through some kind of content delivery Network then we would probably have to do it in a way that we stop writing to Vertical three numerical three start writing to Vertical three in this time uh the pre images appear somewhere to be available and you have time to download it before

you start you have to do the sweeping part that's exactly the suggestion yes okay okay so but that's that's like potentially unreliable right uh to some extent we have to like have a quite a big window for that yes that's exactly that's exactly what I said in the beginning um ideally we would have this window big enough even to um squeeze in an emergency release which is kind of which may be something like two weeks or something so out of the total time for a transition if their whole transition only takes 15 days to make this pack or two okay maybe then it might be simpler and

one of the questions I had is you say it's being uh it's updated like if you have to appear to peer or network you you can update it that's true but then don't you need to implement something like Snap think effectively because how do you know how out of date the thing is yes yes yes yes you have to have this kind of um uh yeah okay um yeah I mean clearly I'm not uh I'm not going to okay for example you can modify Aragon to have like Deltas of pre images and just download them right so for each block you can very easily know what kind of uh items

were added right and you can very easily download it by indexing by block so you know which your block you are and you can download all of them backwards true very simply and yeah and you could also download like a huge flat file at some point yeah like just just get the updates basically yeah there's a question from uh passenger in the chat I don't know the owner got fruit if you have any thoughts on that well I mean

you could of course do that it's just more complicated than with just as I mean if you sort of make this calculation part of the miracle State I mean this would be the idea that everybody has to do this calculation which is examples um and quite heavy and there is it just adds one more thing that we need to think about which is I mean there is not re I don't see really much point about this much benefit of doing this except that we don't have this extra time I mean my I mean my take on this is that the main advantage of actually um only having to distribute um pre-images for a frozen myrtle tree is that there is no reorgs around the transition period so it's been working

with the Frozen with the Frozen Merkel tree when you do the sweeping actually there's a main advantage that um this doesn't change because I mean remember that you need sort of you need to sort of sort this also into the correct order uh to um basically make the um sweeping consistent and this can get messy if you have a reorg around that here again uh yeah I know I don't have anything to add to what you say per se I just wanted to point out that there's actually a proposal by vitalik um that you do exactly this for the the vertical Tree in case you want to change again in the future and uh this is

something that's a bit annoying because you need to evaluate to uh to do a multi X of two more values the one the the address and the slot number but the great advantage of this is one of like the pushback I got from uh members of the guest team especially Martin uh was that you know this new model where everything is spread over the tree he was saying it's hard to debug because it's hard to when you look at a group you can't really Trace what the what where which account it came from Etc et cetera so doing this although I'm not a super fan because of the extra computation involved uh would probably

get us get us a better buy-in let's say from at least from Martin um so it's not completely uh irrelevant I would say I mean yes I would not do that for the MPT but uh there's still definitely a good reason to do it thank you okay

if there's nothing else then we can move on thank you God freed and everyone for the discussion uh Ignacio did you have an update on performance work that you would like to share um yes I will share a document in the chats so maybe some of you have already seen this vehicle so this is like a new version and I will only mention like the end result of doing the changes Because the actual details might be a bit boring for most of people I know um so I basically implemented a bunch of

yeah missing optimizations in our goal cryptography libraries um um that are basically many of them were like already known out there in some documents that get wrote or some articles by dankra um there were like orders that I discovered by looking at the implementation in Rust and they're like others that I simply identify while in digging in all these so in this argument basically if we go into the impacts section uh there's like a brief summary of uh what kind of speed up you can get from like a semi naive implementation

that we had that we already knew that to one where you apply all the ideas and but we got is basically for an example of Sixteen thousand uh polynomial openings we had like 2.5 speed up for proof generation and uh like a 30X we have four proof verification so after sharing this a bit with some people it seems like this is at least in better shape now uh at least what we were expecting so uh there might be some other ideas that we can do

to improve the numbers a bit more uh but that mostly lies on parallelization and things like that uh all these optimizations are mostly single threaded um doesn't require extra memory there are no like more pre-computations or things like that so yeah I went into more detail in the document about what are all these ideas and I kind of linked the ideas to PR's uh that implemented that so this might be helpful for the future other people like implementing things or trying to figure

out what the Goku is doing if they want to copy that at least have a more like coherent explanation of radius um so yeah that's my update thank you okay cool um so one thing that I had that I wanted to share just a quick thing I will share it in the chat this will only take a minute

um I thought it could be helpful to put together a quick overview document of open questions around verkle uh or perhaps more accurately known areas of work that have not yet been fully specked or implemented I won't go through each of them here in detail but if anyone has any questions on these has areas that could use more attention or anything that's just completely missing from this list I would appreciate that being flagged you can do it here in chat or in Discord really just trying to make sure that we are staying on top of everything and that

things that should be getting attention at this stage are getting the right amount of attention obviously there's still a lot that needs to be done as we get further along um but yes so I just wanted to share that quickly I don't know share an abbreviated list here in the chat that was it for me going back to the agenda [Music] I just lost my cousin um yes

[Music] did you want to share a quick update on vertical snap sync work uh yeah I think I can give a brief uh brief explanation of what I'm trying to do I don't have a document here because it's still in Prototype phase and still have to figure some things out so the idea is very similar to what we do in staff sync for model trees but there are few differences uh like first is the healing part uh so since it vocal trees every block have a post State and roofs inside the blocks we don't need technically we don't need healing uh from like we don't

need external additional data from other nodes to heal the tree while sinking so one difference is that we can just use the State tips or Witnesses in blocks to do the healing part now coming to the actual sink part uh yeah so what I'm planning or what I'm going to repeat right now is that instead of fetching the range of Leaves we instead fetch the range of soft trees like basically uh with 31 byte stem we like we fetch the entire subtree as one element this makes the proofs that we need the range proves that we need for overput is much simpler uh yes so I'm experimenting with both of

these like with the law of its pedigree just for leaves and fetchy lenses for sub trees and we'll update on the like the difference in group sizes and the time it takes to say so I was able to run some tests not on two different notes but some unit tests and things like that and this seems to be working uh properly uh but since in constant we don't have we still don't have the post date in the blocks so I cannot test the healing part right now but I think I'll have some more updates on this uh before the next week foreign you don't have the post State

um I'm just wondering would there be a way to somehow uh yeah I mean I realized that this question uh might go I mean it's a bit stupid um but could we just not try to to have the like this the snapshot that would correspond to the restate instead of the post State uh I mean clearly the problem is you find yourself is a patchwork of blocks that need to be executed in different locations so it's a bit complicated but I'm still wondering if we could try to uh yeah okay it's probably not actually come to think of it it's not really worth it

um yeah because uh it's it's only for Cal students so it's not really going to be to be worth it okay sorry uh when you're proposing that we use the free state and execute the block and use the post date to do the helium sorry uh yeah there was more or less it's but then it's going to be like a full sync so kind of kills the points I mean as an intermittent step it might be interesting but yeah um I mean you tell me but I think it's too much for too much work for too little gain yeah it depends like how much time

will it take to implement I'll try to first uh pro drive the current ranges part and if I have some time left I can give it a try because anyways we are processing the blog while verifying the block so we just I just have to add one additional structure that collects all the updated leads I think it should be doable I'll give it a try uh sorry yeah you would be processing the block but I mean ideally you would want to start you know if if for example it's uh it's two years from now uh like two years after the transition

um and for whatever reason we don't we don't add prostate in uh in the blocks uh that would that would just be a full thing it's true that in the short term you will likely uh just re-employment just re-execute the blocks but you want to start from uh from a clean uh for something you know stable that you know is is the correct State and that might be uh yeah Lucas yeah but it will be only full thing for the blocks that were added during our snap ranges part right true yes so it will normally it can be like on Fast machine it can be like two three hours of blocks so not that many blocks

to reprocess yeah that's true okay it might actually be worth trying yeah yeah it would be and anyways we have the because eventually we'll be adding post dates so we have the mechanism to collect the updated leaves we just have not enabled it yet in question so it's already implemented so I don't think so it's a lot of work so yeah we can give it a try actually I have a different uh question

can we process the process those blocks we can during snap ranges yes that's exactly exactly what I was thinking right now yeah we can process those blocks during yeah yeah so this blocks will generate us the newest value and all the old values will be uh from snap ranges this will be kind of similar to the overlay three transition a bit kind of I know right so we we keep the new values from from the processing and the old values are coming there from

overlay and then consensus and here from the snap ranges and they are not inconsistent yeah overlay snapping yeah very interesting yeah so I would say go for that right because that would also decrease the time to think so that's should be implemented without without a doubt either with processing or with uh with what with uh boss state right but why not processing why right I you should start we should even do processing because this allows us to

verify the chain right when we start our node right so why not yeah it makes sense will anyway be processing those blocks so we can do it while thinking also exactly we should okay we should do that definitely okay okay the last thing I had on the agenda in these last few minutes uh is to see

if there are any updates from any of the client teams or any questions uh anything for discussion here I don't know how much progress has been made I know everyone is busy uh since our last call a few weeks ago but if anyone has anything they'd like to share it can be anything hey there I'll be working on a Java implementation of where I could try said I'm just starting so sorry if if any of the questions are stupid but yeah my first question is can we use other languages implementations of

cryptographic Primitives like inner product arguments and Patterson commitment because we will do this in Java so any feedback yeah uh yeah so there's the rust implementation Russ verkle that contains all that stuff more or less directly maybe it Imports other packages but you should be able to call that school the gni uh yeah like Kev would be the the guy to ask he's done that for uh uh like this is how Netherlands started so it's definitely possible and yes we have a repo uh in basil it's a business native repo you have some sample uh to show you how to use the rest Library go library or C library so

if you look at this people it will help you um for a Java it might be a bit more difficult because as I understand you need a draw file which means that you need to compile uh for Windows Linux and mac and then at runtime you choose the operating system you're on so it might not be as simple as um sort of C sharp yeah yeah normally in this report we have all of this uh mechanic to build for all of the platforms so you just have to add some the new library some configuration file and everything will

be do will be did without any problem so okay nice nice so Dragon I can't show you in the next meeting if you want uh in the telegram if you want more info yeah there is also recently our kzg library for in Java that deals with the same thing so these builds for different platforms and then the dni wrapper just choose the right one it could be another reference okay thank you I will investigate on all of those uh are you planning to implement uh like

planning to do everything using the wrapper or just some functions I'm still not sure I'm just learning about all of this stuff so I don't know yet oh yeah so that's what I was trying to say so when I saw so I also implemented the rapper who was the last library and started using that but the amount of operations that you need to do uh on the cryptography to calculate commitments and update commitments it kind of end up being quite a lot slower than what is implemented to us due to the ffi boundary so you might have might want to look at like what functions you want to actually Outsource to rust and what you

want to implement each other because I eventually ended up implementing everything in C sharp because of that in general we are in business we are trying to do all of the cryptographic stuff in the native code or something like that and the Java will just be as a three structure definition or yeah how to how to manage the vehicle implementation without the cryptographic stuff maybe I misunderstood you said the native implementation with the use of cryptography this native mean Java here no no I when I'm saying that TV to see or something like that yeah

I'm planning to uh sort of get my hands dirty and try to sing the ongoing uh word called test match with load star okay I think that is it then unless

anyone had anything else thank you very much everybody thanks bye thanks