Verkle Implementers Call #1

Transcript

foreign welcome everybody to the first ever vocal implementers call thank you all very much for joining we will try to make this as productive and informative for everybody and we will try to keep the Cadence of these calls going forward at a schedule that makes the most sense and we can talk about this at the end of the call

but yes thank you again everybody for joining I mentioned that the agenda is shared in the chat uh feel free to give that a look and if you have any any uh questions comments things that you'd like to see that are not there feel free to drop that in the chat as well so I'll kick things off with a just a high level overview of where vertical is today I think many of you may already be aware of this so I'll maybe just go through it quickly sort of Rapid Fire um but feel free to again just let me know if there's certain things that are not clear or you would like us to

explain in more detail and I may tag Guillaume and others for that but I'll just go through sort of the current state of circle world and then we'll uh yeah just keep going through the agenda items that we have listed out so current state of virtual world we have a test NET LIVE that's actually been live now for a few weeks uh test Nets proofs and blocks which is exciting this this is the costing in test net um sorry and uh on this test mat we have Lighthouse and Geth I believe correct me if I'm wrong here uh okay the lighthouse

and Geth combo has been live now for a while uh anything I think there's also never mind if I'm not mistaken okay could you confirm on the desktop perfect um yes and so uh so that's been as far as I understand it going fairly smoothly and it's all been exciting um beyond that we've spent and we meaning not myself but Ignacio Guillaume donkrat a bunch of others that apologies that I won't put up right now um sorry I'm getting things for more

folks to join um have put in a lot of work over the past few months focused on performance optimizations and again Ignacio Don carat Guillaume a lot of folks have really put in a lot of effort there we now only experience a 40 overhead when replaying blocks compared to the MPT World which is is good news um we feel that we are in a very good position given where we are today uh and uh I think perhaps there are still open questions in terms of what's overhead acceptable and you know we can talk more about that but that's where we are today and and again a lot of really awesome

work has gone into that foreign so where are we focusing efforts today right now we are focusing more of our efforts on the actual Merkel to verkle migration I understand that nethermind perhaps is also doing uh some work on the sync itself which is important of course but a lot of uh more recent effort again has been focused on the actual migration how do we move from the Merkel to Vertical World and so we'll get more into that as well later today on the agenda so so that's just a really quick high level overview of where verkle is hopefully that was at least somewhat helpful uh if

folks have any questions feel free to jump in now if you'd like or again just draw messages in the chat um cool with that I will pause for a quick second and then we can hand it over to DMD one to handle agenda item number two the teardown of Beverly Hills uh yeah sure so um you might have I mean if you've been following Virgo a little bit you you know there are indeed two test Nets there's Beverly Hills which is one that does not have proofs in blocks and does not package the proofs in the blocks and its purpose was just to test if um dabs still work and allow others other clients to to

make sure they you know like in terms of as a first step for other clients who want to support vocal trees to to join other execution clients um and uh well we would like to relaunch it a bit further because currently uh the the test net is pre pre-capella um sorry the other way around pre uh uh uh Shanghai but um yeah we so far uh it's been consuming uh consuming a lot of uh yeah like basically it's been costing a lot of money and it's not really useful

at this point because the two clients that started implementing uh their um like vertical trees already aren't on Cal student so we were thinking of uh tearing it down for a while performing a rebase I mean at least get needs a rebase to to provide vertical in a post Shanghai world I don't know but never mind so unless there's opposition we would be tearing it down next Friday uh and yeah to relaunch it at a later time when when guest is ready and uh yeah if if Netherland also needs a rebase we'll wait for another mine um yeah just checking out if someone is

against against the idea uh both right both test Nets are proof of stake sounds like no objections to it the tear down excellent then yeah we'll publish a a teardown date but it will be it will be next

Friday at uh some uh some yeah European time probably perfect is there any action items needed for me again to Mark here we help uh propagating the information in case uh in case someone did not attend this call but from when I understand most of the people interested in in the topic are here today perfect okay then we can move to the third agenda item which is the overview of the potential

conversion methods uh game do you want to dive into this as well or sure um so I'm sharing for those who haven't seen it I'm sharing the document that Perry and I wrote uh Perry If I say something uh inaccurate feel free to jump in of course and I guess I will also share my screen uh if I can if I can find a way to do this um right [Music] um right that's the okay so yeah this document basically

gives an overview of the of the four methods that we have um or at least they have been proposed and considered seriously um we don't really uh include yeah we don't it doesn't include all the methods that were proposed like but never really uh considered like what we call the the role of appreciation week where we just stop uh producing blocks for for a week giving enough time for everybody to to convert um but there's there's basically uh so there's four methods actually there's really uh two method with each has two sub method or sub approach

there's the overlay three uh which is uh a method I mean I will detail every every single one of them but the idea is that you have two trees and you move the data from the Merkle tree to the to the vertical tree little by little over time um there's uh what's what we call the offline method or the conversion node so this is uh this is a method in which only a like a limited set of computers or very powerful computers do the conversion as uh as quickly as possible and then distribute the results over the network and then it's up to each node to download this uh the result of that

conversion and replay blocks on top of it to catch up with the with the head of the chain before the before the fork before the vocal Fork uh there's the local bulk which I actually I won't go too much into detail uh because it's it's just like the conversion node but everybody does it so it's the it's basically the the hybrid between overlay and the conversion node uh it's mostly the the worst of both the worlds and there's what has been the state expiry method because it has been suggested in uh in um in the EIP uh well in the EIP draft for State expiry and the idea is

that the transition doesn't really happen um the MPT so it's like the overlay except you don't have this process that moves values from the MPT into the vertical tree uh so what happens is that when you want to read the state you just you you go into the The Freckle tree first and if you don't find the data you go into the MPT and um this is a method that is really interesting if State expiry gets implemented because eventually the MPT will be converted offline and replaced and in fact deleted all together and the data that used to be

in the the miracle 3 that was not um clobbered by the by the vertical tree can be downloaded by passing proofs at a later stage but all this is described in the Statics pyria PR sorry not PR EIP draft so just to go uh over them quickly uh so yeah I invite you to read the documents and make some comments but the idea of behind the overlay is you have uh you start with an empty um overlay tree which is vertical and you have the base tree and the base tree becomes read only and then you have an

iterator for both the accounts and the storage and as blog progresses like the as the chain progresses uh you just convert um leaves from the from both the country and uh and the storage Tree in like storage uh iteration order and you move them to the overlay tree and then the method is that if you want to read some data first you hit the overlay tree if you don't find the the data in the Virgo tree then you you go into the base tree the miracle Patricia tree to get your data and this goes on until the whole iterator like until the iterator has

gone over the entire tree and when this is done all the data needs to like that they used to be in the MPT has been converted uh into a converted and placed into the overlay tree and as a result the the data can be deleted and the interesting part I mean there are many interesting Parts but one of them uh with this like the interesting part of this approach is that what has been uh it actually shows uh in the next diagram what is right of the of what I call the conversion boundary so what has not uh what has already uh has already been covered by the iterator can be deleted

um you when you delete that data you do not update the the root of the tree so virtually the the tree remains untouched the MPT remains untouched but the that data will never be read the data left of the conversion boundary will will not be read so you might as well delete it to to save some space and it's got some interesting properties um with respect to sync with respect to uh I mean conversion wise everybody does the translation the translation themselves so um yeah there's no social like social interactions don't really uh

enter into the protocol um but the problem is the number of leaves that get moved from One Tree to the next has to be slow enough that most of the machines on the network the vast majority on the network can keep up so uh translating those leaves has to be fast enough in a way and it also has to be fast enough that it doesn't take forever because you could just say let's take let's translate one leaf per block this is going to take years so there's a small back of the envelope calculation we

estimate that we need where if we manage to translate about 5000 leaves per per block it will take you about a month so that is acceptable and I made this diagram to see that even if we uh if we translate say um 10 000 leaves uh it will still we can still have an acceptable uh replay time um of uh yes exactly in one month we could achieve that with let's say uh 50 of the slots missing so while this is not what we want it's uh

it would be fairly resilient so yeah there's more there's more um information more explanation on how things work but yeah that's the overview for the of the of the overlay method then there's the offline conversion or the like the method where only a few nodes specialized node uh do the translation so we have like three three uh nodes on the network one of them just stops and starts the conversion and then the other two nodes start when it's ready when the state becomes available when the conversion is is done they can start downloading it and then they are responsible for

replaying every block between the moment the conversion started and the moment they they fetched the states so all those blocks have to be replayed before the deadline the end of the fork um so that has the advantage that you're no longer dependent on the slowest uh nodes on the network or at least the slowest notes that you want to keep supporting uh but the the problem is well it's not as um yeah you need some uh social mechanism to figure out that the conversion was indeed correct um and it's also not very uh it's it's not really easy to handle

at least I I try to make a prototype of this um and it found uh and found it was fairly difficult to to implement especially around the fork end because as we know a lot of people tend to download the the latest or uh yeah download the the sorry the release before the fork close enough to the fork so if they have to download all that data and replay the blocks what happens is that I mean the replay will work but it will probably end past the fork and if the majority of the network are a big enough chunk of the network misses uh the deadline you

have a long time without any blocks produced so that's it's a bit risky it's not really practical at least I found it extremely tacky the way I implemented it I implemented it so this is why I mean this is why this method is not favored by me and people working close to me um but of course this assumes that we can reach this speed with the overlay method which we have indications that this is probably doable but it still needs to be confirmed and uh yeah so going quickly over the

local book conversion method like I said it's the worst of both the world everybody uh everybody does their own translation and then replace blogs on top of that uh so same problems than um same problem then then the offline or the conversion node method because if you update too late your conversion will complete past uh past the the fork end and if um it's also bad with the vertical with is also the it has the same disadvantages as the the overlay method because you're also pacing to uh to be as slow as the slowest machine on the on

the network and then the state expiry I don't have a graph for this one but yeah it's it's basically the overlay three except you don't touch um you just don't touch the the base tree you keep you keep hitting the overlay tree first and if it fails you go into the mpg and eventually when State expiry is implemented the mpt3 will be deleted from from The View um yep that's pretty much it for the for the overview let me check if there are questions yes I see some questions um so what is the impact uh regarding performance yeah we uh are currently

implementing um in I mean I'm implementing that in GIF so I don't have concrete numbers but assume it will be right now I assume it will be twice as twice as slow uh hopefully faster than that um and uh yeah I don't I don't have numbers yet uh what's the failure mode for this you screw up at week three uh what are the so I assume you're talking uh which which method were you talking about photos so both the I guess the local conversion one where you it'll you're talking about a month time if you do it at the current speed yeah

and the failure mode is for such a node Perry is saying that uh what you're gonna be screwed and you're gonna be three weeks late yep uh so so if is there any situation where would we'll see like a bunch of nodes failing like right I mean yes um I I assume there will be notes failing we should prepare for that in any case uh but what happens is in the case of the offline conversion indeed like if you're if you find a screw up three weeks into the conversion you have no choice but uh downloading a new conversion and uh and starting over so I think this is talking about the overly

agree method though so for example if I'm doing the overlay conversion over a month right yeah so uh in the case of the overlay three it's uh you you don't delete the data immediately you only delete the data when uh like the the scan of the uh iterator or the stride of the iterator has uh has gone far enough that uh the preview that data has been like uh sorry the data that got converted corresponds to blocks that were finalized so if you screw up before the finalization time you can go back

it's just a regular reorg if you uh finalize something incorrect you have the same problem as the current MPT you finalize something incorrect and you have to uh well you have to go through the mitigation process uh in that case like pertaining to that case but uh how do you recover yes you you will need someone to keep the data to be able to redistribute it um and to and to sync so that other people can sync basically so that's that I think it's what Lucas is also asking so so my question can be rephrased look so there's there's a percentage of notes that need to stay online so that we go across the transition

and after that transition happened then whomever was left over can just download and snap sync uh from them correct yes okay um right so uh right Lucas sorry I'm just uh okay you can speak I'm just reading what you wrote as well at the same time yeah so one thing is uh because I'm I'm all for the overlay three because I think the transition should be in protocol uh doing things outside of protocol is messy and it has more points of failure in my opinion yeah so if we have it in protocol it's

it's better so I'm all for the overlay three uh the two questions are that I came to my mind is the transition time because you were going for one month and the shortest transition time the harder uh are the harder are the hardware requirements probably right because it has more rights it has more reads so especially on uh iops so it would be good for like an average or below average SATA drive to be able to do Transition right so uh what what uh are there any like numbers around that and what would be potentially if we if we find out that

the numbers are problematic uh what would be acceptable transition time how much longer it could take like one month three months six months what would be uh something acceptable I'm just throwing and throwing out like uh to to find like a boundary where it's acceptable or it's one month is the target uh I mean one month is I would say it's the it's the target then what is the upper boundary I mean you guys tell me I I'm quite happy to go for for three months like clearly a year to year that's that's too long but uh I really don't uh mind uh three months personally um in my opinion this should be like

taken um periodically so we should have at some point so we should have this configurable right how many nodes are we are we doing per uh per block and then we should take some relatively slow arm machine that we want to support or whatever it can be x86 and when we will be closed with our optimizations to the to the boundaries then we should like try to just measure it and do that like empirically right absolutely I mean uh so what I can give you is I have a machine with very slow I O and it takes roughly 20 hours to convert um but that's like bulk conversion

uh when it comes to using the overlay tree I'm still uh I'm still debugging it so I can't give you numbers yet I hope to be able to give them uh as soon as uh as the thing has been debugged but I expect yeah one week is uh is probably the on this machine one week is a reasonable expectation one month I would say is the safe uh the safe period oh okay so it's not looking that bad but that's on the slow machine but that's still uh x86 that's uh it's just like the bottleneck is IO by by far uh when it comes to what is the storage layout that is used is it like

Aragon layout or is it more like def layout what is the layout of the uh MPT and Patricia yeah so I have a I have a hard time answering that question because we're about to change it in yes but uh it's uh let's say yeah it's it's a bit in between but um it's yeah okay it's closer to the guest layout mm-hmm it's a path based layout like the new layout exactly okay okay so it's not quite complete but it's that's where we're shooting for you because it depends on the layout right I think in the current Netherland layout which is like the previous GIF layout it might take longer because the reads will be

very slow uh comparable uh to slower but we are migrating to new layouts uh as we speak so it might get a lot faster in the future and I hope we will get there before vehicle tree uh hard work so yeah right uh yeah I think I mean I think Virgo 3 will imply a change in the database layout I mean it sure does already from from what I can I can see uh I just wanted to go back on something you said like uh our machines depends what you mean by our machines because if uh you still want to be able to do that on Raspberry Pi I can't promise you uh

even the Raspberry Pi 4 with 8 gigabytes of RAM which I think is the is the most up-to-date uh that might not yeah that will probably not work and I I don't think we should support that what we should however strive to support is the rock 5B The Supercharged uh one uh because like the supercharged Raspberry Pi because this one has 16 gigabytes of RAM uh I think it's got faster i o so that would be my my cut offline if you ask me personally that would be my cutoff line I don't think we should get rid of arm entirely but I would say we should not really care to save the Raspberry Pi if we have to

also um the rocketpool community has moved to the Rock 5B and is recommending it for rules with low power needs nice okay so then I just yeah I was also saying that I don't think so we have benchmarks for how the code for the vocably works on Palm like we have performance uh differences for our machines but I don't think so we have any Benchmark so it might be possible that that part specifically also becomes a bottleneck a converting and calculating commitments uh for too many leaves insertion so we have to consider that

also yes uh yeah absolutely we do not have if it wasn't clear we do not have uh sorry I'm looking for the word benchmarks for arm beyond the pure crypto execution okay so something to add to the list um and the last question of mine would be okay if someone spins up a node during the transition period he needs to replay all the blocks right in the conversion method yes uh overlay right overlay three uh does it make sense sorry the offline conversion or I forgot what is called the conversion node method yes it has to replay all the blocks otherwise it could simply uh in

the case of the overlay it needs to download the data from uh like the MPT data so that's like Snap sync without the healing phase yeah and then I guess it can just well if if we start putting blog proofs and blocks right off the bat you can just get the the missing data from the Block itself so you do not need to really think Beyond uh uh yeah you do not need to sync the stage you do not need a snap sync for the for the vocal tree but well we have some kind of snap sync for the vertical tree post transaction well what I what I was I mean okay uh I see tanishq is raised has raised his end

because he's worked on the topic more than I did okay uh what I my understanding before I let him speak is that you do not actually need um you do not actually need snap sync but go ahead uh no I was just uh I just wanted to say that I'm not sure that we will be able to add proofs to the block before the conversion completes because we will not have proof of restate so uh I'm not like so that cannot be used for healing and yeah sorry to to interrupt but that's actually not true because when you do overlay the three starts empty so you have to start the you have the the data

from the start so you can already produce proofs but you only produce proofs not for the entire state but just for the overlay tree yeah I think uh the migration so uh we'll not be able to prove that there's a values that you picked up from MPT and then you insert it into vocabulary and then use that value to do an execution so that value will not be able to prove in the pre-stay that's a good point um right but right that's that's true uh you could not do that you could not be able to you would not be able to prove this part but you would still be able to prove that uh you know just uh just the data that was converted even though you can't prove where it's coming from you

can prove that it has been added and then use it to for the sync uh yeah that makes sense produce yeah so I take it that since it is the first talk the first call I can ask the very stupid questions suppose that we are at a past the fork and everyone is running on vertical and I want to start a new node so what's the mechanism to to back sync this node uh Define like all the way from uh from the start well so I I yeah I'd like to back sync all the way from since Genesis right so it depends on the method uh and

once again tennis input is probably the the better one at this point uh on this question but the way I see it is you you start downloading the blocks um okay if you want to do a full SEC let's start with the full thing no no but so I I'd like to to do the cheapest possible thing so I suppose that I can just download bits of the state as we do now with snapsync yep and then download all the blocks and I could just backfill the blogs just by checking block hash or something like that yes okay and then I can start regenerating some pivot States or something like this you could if you go backwards and you have the proofs in the in the block you could start uh well okay once again I haven't implemented it

so I might be saying something incorrect but the way I see it is you can indeed start uh backfilling the backfilling the the state as you go back as you go up the chain or you could simply download it at a given point and only backfill Sorry download the full view of the state at a given point and backfill uh up to that point basically oh I see uh will there be a like a state downloading mechanism or because I see that at some point this will be slower than downloading just the state uh yeah it's I mean the the point is

indeed to have pretty much something like Snap sync except the healing phase is replaced by uh by the proof you find in the block okay that's the general idea like I said I'm talking uh this is the most theoretical part of the of my uh of this meeting uh it hasn't been tried that explains how I get to it having a running node but now I want to to say how much my like they put it the way that Peter wrote it like how much my ex-girlfriend spent that day two years ago before Virgo how do I get to see this on the note that I just spawned off

uh yeah I mean in in that model uh okay so how do you go back all the way uh past the past the moment you downloaded the data yeah you just go back in time uh and you look at the proofs and the proofs will tell you oh this is the I mean not not even executing everything you just look at what's in the in the proof uh like the proof data oh I'm sorry okay so I think I understood so the proofs this is something that I misunderstood completely from Virgo so the Brooks are going to prove the full State even before the verbal transition uh no no not in that uh no that would not be the case oh then then how can the blood proofs prove me

something about how much my ex-girlfriend spent two years before the transition right so that's that's the part uh I mean I would really like to let tennis talk him sorry for hogging the thing but uh the the idea would be that at some points uh indeed like there's there's a conversion happening of the the whole uh I mean okay either your girlfriend spent uh something before the fork in which case it will be found in in the blog proof otherwise you have no other choice but you have to I guess to full sync if it's pre pre-workout Fork you have to full sync I guess or archive find an archive that will tell you archive note that will tell you

what what you need okay yeah so I need to I need to so and people are aware of this so I just wanted to say that I think the mechanism will remain same as it is right now like in the current situation also if you want to uh get the answer to your question you'll have to do a full sec because snapsing or fasting you get a state for a particular block but like you don't have the previous day uh to verify or question like what was spent two years that so I think you anyway have to do a full or anti-sync and the method will remain exactly the same in

the vocal scenario itself you'll just do a full sync and at the point of transition like right now you are converting 5000 leaks every 12 second but while thinking you'll convert as much as you can [Music] uh sorry yeah because I realized uh we're getting close to the the end of the call I I'm happy to stay a bit longer just want to make sure that uh we proceed to the to the next topic if uh and and take the and take produce question offline I mean yeah go ahead oh I have one more question uh open question maybe because with vertical trees we are now bloating the blocks

right so the blocks will be a lot uh how much how much bigger the blocks would be like 50 100 more uh our estimates was like Yeah a hundred percent 100 more so looking at the database size the blocks are currently half of the blockchain size on disk uh with State pruned right now so we are bloating them a lot more so vertical three will probably expedite four four four four or was it the one that state that you can expire blocks right uh from the network a lot because that would be a big increase in size yes of

the block database so indeed if you can do that it's better yeah yeah I think it will like be an necessity quite soon uh because of that and if we get there then we cannot really rely on replaying proofs from blocks because they might not be available on the network that easily maybe the portal network will be uh handing that but we'll see how it goes right um so again there will be a need for like a state uh sync uh for the vertical trees at some point like completely yeah absolutely um I mean like I said it's like Snap

sync with Virgo used as the as a healing uh as a healing method um there Josh there are still some questions but uh I don't know was it the hard deadline is it supposed to end in two minutes um supposed to folks on the call I I realized that maybe I should have made the time a bit longer for the call for folks that have to drop off because I scheduled it now um otherwise we can continue and and for folks that have to drop off I can I can provide a summary of the conversation but perhaps we should have a hard stop in the next 10

minutes or so okay yeah absolutely I'll try to just answer the questions uh quickly and then we can move to the next agenda anytime um I think that would be required but now uh okay uh G11 Tech I'm not sure I understood your question if you're still around okay I'll skip um right so would archive nodes will have to keep a pre-veherical state um yeah sorry go ahead yeah yeah so uh I think uh my question was around snap sync only so I so once you

mentioned that snap sync won't be quite so I was a bit confused having something analogous to synapse sync will be required right uh something analogous to snap sync will be required yes okay thanks um right Barnabas was asking uh we'll have to keep a preview course date I mean it's kind of the same question in a way uh depends on the method but uh yeah the pre-versal state will be required to reorg during the transition but once it's done unless it's the last method the state expiry method you do not need to keep the the pre-workal states

um and with this uh maybe we move on to the next topic perfect so next topic uh one second let me bring up the agenda again I have another question uh so the current uh CL spec so uh which basically has stem proof so what what method does it correspond to or is it same in all the methods uh sorry I didn't quite get the question like the the sales pack yeah it contains proofs like you add proofs to the

execution data yeah Yeah so basically you have so again uh let me rephrase the questions because I have more than one so there is straight root and then there is execution something right uh yeah so so State Route will be frozen there is execution Witness uh the straight fruit of the MPT will be frozen yes okay so then the execution witness will then carry uh the workers mortal root right uh yes the execution witness will only contain vertical information and then there are list of proofs so what are these I mean I was just taking

them out and no no it's not a list of proof it's um it's a list of locations that got touched in the tree in that particular Block in that particular block okay and so basically this is independent of any of the transition methods this is uh yes it's only dependent of what got executed but of course if the transition method touches some areas some locations in the code or in the data or wherever they need to be added to the proof for verification okay thanks great next agenda item is query image

distribution Perry um Perry since I guess since we are short on time do you want to go through a quick version of this or would you prefer to wait until the next call completely up to you I can go through a really quick version of this um so there's a couple of ways we can look at pre-image distribution as long as we can make sure that it's extremely easy to verify what data we've received we could probably use a combination of either cdns and follow a similar strategy as we did with checkpoint sync where we can either make like a service that is easy for a lot of people to run um and enough people on the network can

altruistically run these endpoints where you confess the pre-image from additionally we can share this by torrenting and a few other places so it wouldn't necessarily matter where the users get the pre-image from um as long as we make it really easy to verify I think that's the that's the gist isn't the problem here that the premiers will be already outdated when you get them because the network will be already further down the line and some pretty images will be missing exactly so we have to rely more on CTN style methods with really why not why

not just code it into some protocol like Snap sync similar protocol in into them why not the simpler solution is like just make an upgrade of the client at some point that starts recording um pre-images from then on uh okay and uh you so you only have to distribute historical pre-images before that point in time okay but that's there's one potential problem here so the client can record three images that would be had to be hard Fork so everyone would record from this point that's like a bit problematic right because okay mm-hmm yeah yeah I guess you well I mean

it doesn't have to be a hardcore it just has to be an uh an agreed date it's not a hard fall it's a at most kind of uh I could stress the point in time where we all agree that we started but there will be nodes that will miss that and we cannot leave them behind right so people who spin up later yeah be able to cut right well then they would have to get the diff from somewhere as well yeah but if I may add uh so there's any IEP describing exactly this that I created 68 something I'll copy paste it uh if I would say if people don't upgrade uh like it's it's some kind of if you decide on a date it's like a fork even

though it's not uh you know it's not a proper Fork it's just some feature that gets added if people don't update by this time it's like if people did not update uh before the merge they they simply drop off the network um if they don't follow the protocol they drop off the network that's that's the point so I I think that's a big problem if they want to rejoin the network they need to be able to download all these divs from the date we decided to record them to the date they rejoin because otherwise they won't have them right because they want to play all those blocks yep that's true any other thoughts there parody

uh no I don't think there's anything else for me um I'm trying to remember what we discussed about why we don't want to just add this to the sink but I can't seem to find any notes on it any Eon remembers um uh just pure laziness we'll be told I'm not sure if adding it to the sink wouldn't be a similar amount of work and it would be more stable and reliable I agree I think one of the reasons the um uh change the P image over out of protocol method was enticing earlier was if we were to go down the conversion node method where there's enough out of protocol Concepts to begin

with but if we're not doing that at all and we're going with everything in protocol it does actually make more sense to probably include it in sync yeah that's true we we can we can work towards adding this it should be for VIP yeah and it's more Standalone than right you don't have to rely much okay the Aragon would probably start uh uh the the initial stars but then it would spread out to other nodes and wouldn't be a big deal okay well if folks agree we can maybe

pin this for now and we can come back to this in the next call in the meantime we can continue the conversation of course um do you want to quickly go through the we really just have one last agenda item which is where should client teams get started yeah uh I'll give a very quick overview and then people can contact me or or tanishq if they have more specific questions uh but okay so there are three things you you should do uh if you want to get started look at the crypto because this is uh yeah this is what the rest of of the whole effort is built upon um yeah so Kev would be the go-to guy I

guess for for this uh if you want to implement the crypto yourself uh Owen of course there's also Gotti uh um yeah so and uh what else yeah the so I would say try to join Beverly Hills that's the long-term goal uh but we will relaunch Beverly Hills so that's if you're an El developer uh if you're a CL developer try to join Cal student uh because currently we only have Lighthouse running um it served us well but uh yeah like you you have a reference uh just to try to to implement this spec basically and uh there was uh yeah of course the

the other thing you can do is read the EIP draft in any case and uh verify verify the data model uh yes right so especially when you read the EIP make sure you understand how the the tree is built because this is what has the the biggest impact on the on the design on the software design and just that's roughly what it is and then if you have if you have questions uh of course uh shoot me uh either contact me on telegram or on the on the Discord Channel Enrico has a question around the uh spec

for the CL side yeah it's still a PR I don't know why uh it hasn't been merged I'm copy pasting it right now here we go too many windows so it's yeah it's currently a pull request perfect thank you okay anything else Guillaume I think the only remaining question this is maybe um just for you and uh in terms of when we'd like to have the next call what is the Cadence that you're thinking for the ski on anyone else um yeah my my opinion is currently

there's not uh it's mostly like we're trying to get some benchmarking so as far as I'm concerned uh I'm happy with the call next month like first week of June uh but of course if people feel it's necessary to to talk more often I can do that as well okay unless any other thoughts or objections we will I will schedule the call for them make sure that you all are on the invite uh ping me if anything else comes up in terms of scheduling and yeah do you have anything else before we end

nope thanks for organizing this of course and thank you everybody of course for uh for being here it's all very much appreciated and um yeah thank you for joining the vertical effort all right guys bye thanks bye yeah bye foreign