Whiteboard Series with NEAR | Ep: 5 Justin Drake from Ethereum Foundation |
Nothing is loaded from YouTube until you press play, and then without tracking cookies.
About this video
In the fifth episode of our Whiteboard Series with NEAR, we had Justin Drake ( / drakefjustin ) from the Ethereum Foundation speaking with our Co-Founder, Alex Skidanov ( / alexskidanov )
Download the video here: near.ai/6ada
------ About Whiteboard Series --------
The Whiteboard Series with NEAR is a set of video interviews with Founders who are building scalable solutions for Blockchain. We deep dive into their story, what they're developing and how it is helping the ecosystem.
Follow the latest from NEAR Protocol on,
Discord: near.ai/discord Medium: near.ai/medium Twitter: near.ai/twitter GitHub: near.ai/github
#FutureIsNEAR #BlockchainProtocols #TechTalk
Transcript
12,950 wordsCaptions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.
- 0:02
hi this is Alex from here and we are at Stanford campus with this whiteboard the place is provided by the Stanford blockchain Club which we're very thankful to and with me today is Justin Drake from aetherium foundation thanks for coming thank you and we're going to talk today about the theorem starting we're going to go into a lot of technical details and to start off can you please describe in high level how the theory on starting will work okay so
- 0:33
I guess before talking about shouting maybe you should talk about the beacon chain absolutely so actually maybe I should talk about a film 2.0 as the whole design space so it's a new system that is somewhat separate from the current 1.0 it one of the main links between FM 1.0 and 2.0 is the economic layer so the if the tokens that a valuable month we know will be used to bootstrap the theorem 2.0 and I guess
- 1:06
the high level diagram is that you have you have 1.0 here and then you have the the 2.0 chain here where if can travel from here to here and then travel back maybe at some point in the future yes it you know it might be able to travel back not necessarily at the consensus layer but using exchanges and other things and you have a hub-and-spoke model where this is the hub and then you have all
- 1:45
these shards all around it and the idea is that each of these shards is the equivalent in terms of fruit put of 1 of 1 if you're in 1.0 and there will be your thousand shots so you get a thousand times the scalability and the idea of this beacon chain is to basically be a central coordination point I like to call it a system change which handles all the non user transactions so all the transactions that will happen in the user land would happen here and here you mostly have
- 2:25
system level transactions who and so what sort of consensus and Sibyl resistance and like what are the properties of those a system chain and the short chains how they operate okay so the 2.0 chain is a proof of stake chain so you you become a validator by making these deposits to become a valid data you need 32 Eve and you be the the way that the the chain advances is with by basically randomly selecting block
- 3:12
proposes so you have the the pool of validators and at every time increments which we call a slot you would select a new block proposer and the in addition to blocks you have so the the block creation is like the the weakest way that the chain can progress that's the beacon chain now we also have a notion of attestations and so without attestation that would be just Depot's effectively delegate approve of stake so
- 3:57
who's delegating to her yeah that's not quite delegated prefer stake but but that would be like the most vanilla proposed existing right there's one person proposing a block every time sampled from the pull of validators so i mean at this point i haven't specified a focus rule but you know if if we had for example the longest chain folks rule then it it will look somewhat similar
- 4:17
like a proof-of-work chain i see but one of the things that we want to do is that we accelerate the process of confirmations so you know instead of having to wait for hundred confirmations we get the hundred confirmations as soon as possible and the way that it worked is that in addition to having a single block proposer per slot you also have a a committee and this committee is
- 4:48
invited to make at the stations for for this block to to vote on it and each of these votes basically acts as the equivalent of one confirmation and and committee is also sampled yeah the committee is also randomly sampled yes and how big is the committee so you actually have a thousand committees and each committee will be of size the number of validators divided by a thousand so basically you have one committee per shot and we have a
- 5:27
thousand shot exam and but which committee do all committees attest to every big enchained block or they also rotating in some way on the beacon chain okay so the way that it works is that we have a notion of epic and so in that pocket is going to be 64 slot and in each slot we try and put an equal amount of committees so of the 1000 1000 divided that by 64 will be kind of assigned a a slot it's like 16 16
- 6:17
committees per person yes so effectively so let's say that every committee is like 120 8 validators mm-hmm and we would get like 2000 relative there's a testing right first of all all right so the other stations when they get included on chain you know can can come with a delay but you know the the the the basic folks are always basically to look at all the other stations that have been made and one of the ideas is that in every epoch every
- 6:56
validators invited to make an attestation and the the folks rule that we have is what we call LMD ghost last message driven greediest heaviest observed sub tree and basically the idea is that if you have a a a trio of self having blockchain you have a block tree and you want to choose y where you build you basically look at the the last message that every validator has made and then you take the sub tree which has the highest weight where one attestation
- 7:43
corresponds to one unit of weight and it's organ validator maliciously created multiple for the same slot you're just discarding all of them effectively yeah so even so it's actually up on the per app hoc basis yeah it's slightly stronger thank you so and within the epoch for kids rule is the same yes so the you know the we could use ghosts everywhere I see but like effectively you will first invoke fortress rule / epic level and then when you find the epoch with a debug there are also blocks
- 8:19
for you so like so the the the folks are so that we have is actually a hybrid folks with rule but one of it is involves the finality gadget and part of it involves the LM d ghost right now I only describe the LMD ghost and that's on a slot by snot basis oh it's not by sight I see yes and finality gadget is so the the financial gadget so the LMD goes you can think of it as more of the local folk toys rule and the financial
- 8:51
gadget is more high-level and it's meant to and that one works on on so-called checkpoints and the checkpoints are going to be epic boundaries and so that works on the network by epigram sounds like it thank you let's say that this is the network boundary so I say there is a nipple boundary here and let's say that the finality gadget finalized this block so will invoke lmd goes from here and
- 9:23
like yes so I kind of like to think as the financial gadget as a optional thing we could just go with a ghost Adam D ghost and that would be kind of a focus rule and that would kind of be our consensus algorithm but having finality is useful for various things one is that you know it gives a certain get strong guarantees about the beacon chain and I guess number two is that it is really helpful in the context of crosswalk
- 9:52
communication because basically the the the the beacon chain is aware of the various shots and so if one shot wants to talk to you another it has to do it via the beacon chain and so you want these communication path between the shards to be really strong and they're from the consensus layer that maximally strong once you have finality of the beacon chain right and so for the crosser communication ideally you would wait for the finality gadget to to finalize the block where
- 10:25
the well we didn't talk about cross-links yet so it's a let's get back to it so for alum D ghost so after a look at the last I just at the last attestation that was my last women delay the highest slot number right yes right so once identified all the highest lot numbers at the station's how do I proceed next with their choosing their mm-hmm the canonical chain so basically you have
- 10:53
you have a weight everywhere so let's say you know three people voted here and then five people voted here and I know seven one I don't to another vote on the entire chain all the way down today it's rectly now from the latest messages from a testers mm-hmm starting from this block all the way down to the Genesis effectively yes someone had their last message here someone here someone went to fly in the wild back and head here yes but and that K we will use this one
- 11:30
even if it's in the past yes I guess it doesn't matter because mm-hmm so that you're right there could be someone here here this is let his last message he went offline and yeah I didn't have any messages here and then the highest score wins the high score wins yeah so basically you take the sum of these two you have you know eight and then eight and then you take the sum of these two ten well actually of all these so here you have eight and
- 12:00
then ten plus you know eighteen yeah and it seems like vanilla LMG even if you see every single a tester carrying the their latest attestation in a given chain that chain even though very unlikely but in principle can still lose to another chain right yes yes but then once you have the notation gadget finalizing then depending on this properties you might require at least some press the short bus or like specifically if
- 12:41
it's Casper f of G which it is right mm-hmm then you need at least 33% of validators to collude right do right so if if you have a finalized checkpoint and then you have an inconsistent other finalized checkpoint then you need one third of the validator to get slashed so it's a it's an economic guarantee at least one third at least one that you probably ballistically that would be super unlikely right like most likely you're going to be closer to 2/3 in terms of how many relatives get slashed
- 13:13
well we don't know I mean we're making honesty assumption or rationality assumptions you know for example we might assume that 2/3 are honest and basically what we're saying is that two-thirds of the effort that has made the deposit is honest but that's just an assumption we don't know if it will be true in practice makes sense but but the yeah so I think what you're saying is that even even if 1/3 even if the third
- 13:44
honesty assumption is not correct at least someone will lose a lot of money right so in a way you can think of it as being more of a rationality assumption than an honesty assumption cool ok so let's get back to the stations so the beacon chain is the only effect of the source of information that is global to the system right yeah so the information about the stations has to live on the beacon chain so at which point is really and you think that the stations can can
- 14:18
arrive late mm-hm and where the stations get stored so the the attestations get put into blocks they don't necessarily get stored and I mean they get stalled for a short bit of time but then we discard them and the specific rule that we have is that you have one epic to include at the stations on chain and one thing that I didn't mention is that these these attestations actually aggregated at attestations so each individual validator will make his own attestation
- 14:57
and then you can aggregate the attestations and we use BLS signatures for that and one of the nice things is that because the attestation from a data standpoint is the same message for all the validators within the committee the aggregation works really well it's so from the point of view of the beacon chain in every epoch you could have a million validators who've each made a
- 15:22
vote but from the point of view of verifying the attestation you only have a thousand different messages and so the overhead for the beacon chain is only verifying on the order of 1,000 messages right and each message would be the BLS signature and in a big masquerade right so we have an aggregation bitmask which specifies which so you once you're given once you have a well-defined committee
- 15:54
you can have one bit per validator and the ones will basically specify who is being aggregated in the current BLS aggregated signature and so by the end by the end of the epoch do we assume all those do we use all those at the stations as a sort of kaspar votes or or or caspere happens separately uh-huh yes so we use at the stations for many many things so this is where part of the power all the the of the film design
- 16:34
comes in is that we have a single message which we call an attestation which there's many many different things on the one hand it does it participates in the lmd for choice rule the other thing that it does is that it wants debates in the casper find a tiny finality gadget but the other thing that it does is that once you have at the stations which meet a certain vote threshold so for example two-thirds
- 17:07
of a given committee have made the same attestation then that attestation becomes a so-called cross-linked but that data station especially before we go to the short chains yes at the station also is an endorsement for Kasper right I'm not I don't be at the terminology of Kasper but be yes like you're testing and Caspar operates on the epoch level right mm-hmm so there could be you're at the station to the
- 17:37
specific epoch yeah and in Casper am I allowed to provide the two stations for two different blocks in the same epoch behavior or is it right so the so the way that it works is that in Casper when you make so you have you have a notion of epoch and that people coincides with the epoch like that's the same epoch mm-hmm right yeah and basically for the purpose of coordinating all the
- 18:10
validators we we have them vote on these boundaries and these boundaries happen roughly every six minutes and what it means to make a a vote in the context of Caspar FFG is basically to specify a so-called sauce and then a target and then to make a vote like this and the we have slashing conditions one of which is that you in order allowed to have you know one vote surrounding the upper vote and you're not allowed to have two votes
- 18:55
with the same target and when I'm at testing to a particular block in terms of like like for the sake of Kasper is it effectively endorsing the previous boundary yeah so if if you're making an attestation for this for this the block at this lot then yeah you this would be the the target would be the the the closest boundary and then the source would be the last justified make sense
- 19:36
it's a question let's say that like like effect these are the last justified book this one so far is far from being justified and let's say there's 100 validators and this one happens to have its core of fifty one let's say right so there's 51 validator who attested to this book okay it's known to me and there's another block competing also the e-book boundary which is like the C 49 right so there's a decent chance that at
- 20:07
some point it's almost metastable right and so there's a decent chance that right now I think this this chain is canonical so the the the the threshold to having this vote be meaningful on a global basis is two-thirds not one half right but let's say right but this is this is not this is not casper score this is the hello amigos scores 51 here it's 49 so okay it's really close okay but like 51 is still bigger so from my perspective this is the canonical chain right now mm-hmm
- 20:42
and let's say I'm on I'm on a tester oh but I only have one slot every desk has exactly one slot I see I only have one vote one pair pock yeah okay yeah so that's so yeah okay that that sort of makes sense now you say that one epoch is 64 slots mm-hmm and then Casper one epoch is every six minutes yes does it imply that once Locke is like every 10 seconds mmm 6 seconds 6 seconds that
- 21:15
doesn't seem to work out ok so sixty-four times six seconds we haven't finalized the numbers but it's on the order of each slot is on the order of seconds and each I focus on the order of minutes okay makes it cool so now back to the now I guess we can start introducing short chains today now it does make sense if you have six seconds then that's six point four minutes no is it yeah oh yeah it is
- 21:55
mm-hmm yeah so six point four minutes not six month sounds like yeah it is okay my math is a bit rested today okay so short chains mm-hmm they are tester one day a test and they accumulate the BLS signatures what is the input to Tour design on is it the the latest so you call you call the house of the block block route right it's not called block house anymore yes it's called blocks yes the same terminology on the vacant chain on the short chain yes and the reason is that
- 22:40
like traditionally when you have when you have a block what you do is that you you hash it and you get a numb number but actually what we can do something a bit more clever because each block has structure in it you know will have it will have a header and itself the head above itself have lots of fields and so what you what we do is that we basically build a a hash tree of the various
- 23:04
fields and so what this allows you to do is to very succinctly prove you know that this field has this specific value on in this block so this is actually a merkel root we will will identify blocks by the milk or root not by a hash I see we're just sort of do a hash right it's still a hash but it's more powerful yeah right and so I'm as an ax tester I'm small or like rather the committee as a whole yeah it's specific to a particular shirt yes and so in that part were also producing blocks simply also using LMG
- 23:49
goes but without Kasper right yeah right and when I'm creating this attestation it is it it is both conditioned on the on the last block in my chart right and on the last blog that I endorse or rather like what is the input to the like what am i competing the signature on okay yeah so also for coordination purposes we will have the committee's vote on upper bound Rees in the shot and
- 24:23
it's the same 16 64 spots mm-hmm and they will basically take the block route at that epoch boundary and part the other the other message data that's included is going to be basically the the shard block route at which the committee is assigned here and it will also include the closest boundary and then we will include the previous justified check on the beacon chain on the beacon so there are three hashes at
- 25:03
least three hashes here other things that that are that are done at the individual level is going to be what we call a proof of custody so not only are you voting for a block root but you're vouching that you've actually downloaded the data that's underneath this this block root and as well as the data in the in the recent blocks I see now the aggregation is only possible if what I'm
- 25:36
what was input to my signature is exactly exactly matches someone else's right so that works well if we all agree on the previous on the boundary on the short-chain block and on the last justified block right so do we somehow communicate in advance to make sure that we're all on the same page or is it believed that most of the time we will see a consistent so the focus wall has these nice convergence properties so we basically use the focus
- 26:06
rule as as our coordination mechanizing so for example if if we are to our testers in the same committee and our state is not consistent mm-hmm effectually as we are aggregating it we would like it we'll just discard my like let's say you you agree getting your in my signature we'll just discard mine right so it's okay that if there's inconsistent attestations and they can all get included on chain and but that cannot be in our single signature right you cannot aggregate signatures if the
- 26:39
input was different right so BLS does allow for aggregation of the signature at the data layer even if the message is different what becomes suboptimal is that the verification cost is going to be one pairing distinct message so the most even though you've aggregated the signatures at the data layer and you've saved a few bites the the bulk of the cost is going to be verifying that pairing so yeah it's it is suboptimal it's possible that every shard will lead to multiple other
- 27:13
stations but but how is it stored so in the way I see what the compression is coming from is that you're saying here's the so let's it can meet you from chart five and you're saying in the block you can say here's the hash over or like block code overall of the last bound to our shark and that's 32 bytes and then you say this is the last justified message and this is a last beacon boundary right mm-hmm beacon root and that's combined
- 27:52
like 100 bytes give or take and then and then there's an aggregated signature right yeah and the bit mass now if they agree 18 different messages isn't this yes exploding and which starts occupying a lot of space right so all of this will have to be communicated several times per shot on the beacon chain so one of the things that we have is that in each block you can only put so many Atta stations and there's some buffer so that we allow for duplicates per shot we also
- 28:31
have a micro incentivize incentivisation scheme which basically incentivizes the block producers to pick at the stations which maximize the number of voters that are being aggregated and specifically new voters that haven't been seen before so basically we're trying to incentivize the the beacon chain being aware of more voters that it that it wasn't previously aware so one question is so let's say
- 29:06
that everyone actually does have a consistent view and the answer the signature is aggregated on exact and and everybody had the same message that they signed on will we for those and these like 130 stations will it be just one sort of in the block will it be stored once or will it be stored 100 times if like let's say this is 64 bytes right and this is 100 is it going to be 100 64 bytes total or is it going to view 100 64 bytes multiplied by 100 if we're
- 29:39
looking at a single shot then it's going to be times 1 and on the beacon chain there's gonna be times 1 times 1 as well yeah but but now let's say that the test were like split and so you have 250 of them so one yeah then this times two I see and then the limit that you have that says like the number of at the stations is a number of unique messages effectually right and and the ones that will be stored are those that have the
- 30:04
highest number of a testers so we do have a notion of short-term storage so we do put the attestations in in the state and the reason why we keep them for some period of amount of time is that we want to see if they eventually reach the threshold of two thirds because once if they do then they become special for the for the finality gadget yes but also going for the crosslink yeah more for the crossings actually an - gotcha - yeah and that same here I'm
- 30:37
the tester and I see something that is being justified that is justified at this point by the F of G and I'm attesting to that and I'm as an i as an a tester I want to maximize my chance of attesting to the same messages as the majority of the people in the future right so I'm I'm the tester for the very first slot mm-hmm right and and I'm and you're saying I have an incentive to attest to what the majority of the people in the epoch will attest yes because you only have one told right but
- 31:10
isn't it expected that throughout the epoch Transperth of G can make progress or cast referred you can only make progress when the Ibuki is finalized only when the POC is only at epoch boundaries right but it can still make progress wants messages from the previous slaughter right right so some because there's some time for the other stations to to arrive so okay so so we break down time in epochs in
- 31:40
each epoch you have slots and you have at the stations coming in you know possibly duplicate per shot and then here we do basically all the accounting will just tally up all the votes and see which ones have you know reached the - felt fresh hold those become cross-links and we also do a tally across all the attestation and we see that if that reaches the the 2/3 threshold so that you can advance justification and finality and that would do before we move to the first slot of the next epoch yeah it's like
- 32:14
right before it's like at the end of the Sepik the last lot of this ibaka right so now when we so let's say we are not at the boundary yet we're somewhere in the middle yes and I'm attesting to something something my the station does not have to be included in the next block to be considered for the for the LMD goes to right so it doesn't have to be included at all to be considered for mg Ghost I just need to be seen well MD Ghost includes often messages mm-hmm
- 32:44
for the purposes of including unchain we have we have two things going on which are kind of just implementation details number one is that we don't allow other stations to come in before for slots after they were made and the reason is that we want to allow for at least four slots for the other stations have time to aggregate so that we don't have lots of fragmentation and the other rule is that another station is to come in one
- 33:16
Airport after that on chain otherwise it can't it won't it won't go on chain can you elaborate on the one epoch after that the second point so basically we want to include the other stations on chain for the purposes of cross links and put purposes of finality but cross length and finality is the way we do the accounting we only do it for the recent past so if you're at a station is stale it's very old then we don't allow you to
- 33:54
include it on chain I see that make sense and now going back to my previous question so I'm an attest trauma testing to something for that to be considered by someone for the lmd goes true that needs to arrive within four slots no no the L&D goes also takes it to account of chain right but I mean more like they need to see my the station then it is before they move to to slot that +5 right so like if that was zero and then here is
- 34:27
load five if someone is that's what five already they were and my the station arrives they will not consider it no you considered immediately so if you make an attestation for this block you're broadcasted off chain and everyone who's received it must consider it within four slots no immediately I see yes no what I'm saying is that let's my message was delayed by four spots oh it was four seconds okay delayed well let's use
- 34:50
let's avoid four because four is the parameter we use on chain let's say five yeah then it will only be considered when it's received of course mm but what is then I probably don't understand what what is the four spot huh so in addition to other stations being broadcast and aggregated off chain they need to be included on chain but we only want kind of very well aggregated at the stations to come on chain otherwise we'd have fragmentation so we'd have let's say we
- 35:25
have a committee of 500 people and then you know they get bashed in in in batches of 100 and so we'd have five different at the stations that would go on chain and so that's five times the overhead on the beacon chain in terms of verifying the aggregate signature so instead what we do is that we say there needs to be at least four slots of aggregation so that the aggregate at stations that go on chain will be very
- 35:55
well aggregated I see so assuming that everybody has consistent state and everybody's signing on the same message we would get Forex overhead in the worst case in terms of storage and verification because like the first block will have some a testers aggregated second to have some third fourth and fifth cannot have anyone know so let me try to rephrase yeah the way I understand it okay and you tell me that's correct so so there's 100 people here mm-hm and they they
- 36:28
aggregating they aggregating data stations and so some of them will be included in the next block right no at the very least you need to wait for four slots o for slot is you see it's not the maximum number of blocks is the minimum number of blocks minimum yes I see yes okay makes sense the maximum is gonna be four plus one network four plus one ebook so in the worst case which is
- 36:53
probably not really achievable you will have some signatures and the block T plus T plus four Sam in 2 plus 5 all the way you have the G Plus 68 yes exactly nice but if data stations and for the and for the purpose of the of the finality gadget are we using at the stations that we in do include of channel stations or we only include at the stations that in the blocks no so I guess Kasper FFG finality is is
- 37:23
objective so the beacon chain is aware of the other stations and we only consider those that have been included on chain but data stations that happened in the last slot mm-hmm by the time the boundary happens they are not included on change I tried they only be included in mmhmm right in for blocks right right so is Casper finalizing the the one even before that yes I see exactly okay so Casper is like one full epoch and one partial epoch behind always so it's like if we're in
- 37:59
this epoch right now then Casper OS what I mean it's finalizing this bonding yeah but in the in the best case the the first 64 slots are sufficient to final to finalize the previous so we don't need to wait for the next boundary no like affected a which one we only do processing at at boundaries and we we progress justification and finality as much as we can oh what you're saying is that even though some of the signatures are you late yes by this time it's already have
- 38:35
2/3 of them yeah exactly and the refutation oh but then the signatures this is one there is one thousand shirts right and so the message that the tester is standing on is different obviously a personal twin shorts per chart yeah so the verification will be the verification for the purpose of the half of G will be thousand times slower right because you see you're saying it's linear right and the number of different messages mm-hmm right so the thing is that we we process
- 39:14
the attestations and we verify the signatures on a stalled by start basis and then we include them in the state the recent at the stations and then when we reach the end you don't need to check them the signatures anymore because you ready to check them previously oh yeah sorry that we don't you try aggregate with across charts we just you know we yeah in theory you could do it but we
- 39:34
don't do it awesome and I guess we can as well while we talking about aggregation talk about proof of custody mm-hmm how does that work and what it's trying to achieve and how does it affect the signatures yes so so if you look at an attestation you have kind of you have fixed data here and then you have your signature and then you have aggregation bits field and then we have another bit field which
- 40:24
is going to be the custody booth field and so the idea is that for every validator in a given committee we're going they're going to commit to one bit and the idea is this this this one bit statistically speaking will be zero or one 50% of the time and if they were to choose the bit at random and not do that homework which is to download the block then 50% of the time they will be wrong
- 41:08
and being wrong is something that can be verified at some point in the future and something for which they can be slashed so with very little data basically one bit validator were able to enforce in terms of incentives that validators that create the data stations have actually downloaded the data in the shots that they're voting for and and how does it affect the signature verification aha or rather what are they what is the message they sign on now it includes they
- 41:52
arbitrate or it includes bits over yes as well yes you're right so if you take an if you take an individual at the station you won't have the aggregation but field and you won't have the custody bit field you will have a signature which is non aggregated and then there'll be an extra bit here which is 0 or 1 and now what you do is that you do two aggregations you do aggregation over all the messages where the first bit is
- 42:16
0 1 where the first bit is 2 and then what you can do is you can further aggregate these two so you have a single idea of signature but from the point of view of verification it will be 2x because there's two distinct messages and is there a plate and then aggregator bit field and the custody bit field the custody bit field the bids at the positions were aggregated bit field is zero they meaningless right so you can sort of Ono
- 42:47
knows it if the aggregator bit field is zero that means like oh yes oh yes if it right so we so if you have a zero at position I we enforce to travel zero at position I here as well mm-hmm right but but but if if if we get too concerned about space that can be compressed into ternary mask right yeah so at the networking layer there's actually just one trait okay so it is already that's already how it
- 43:18
works well the the the networking layer is kind of independent of the spec the implement is do whatever they want and if they want they can't compress it forever but this is so small anyway it's not the bottleneck so if so you're saying implementers can implement the networking layer compression compression but our aren't protocols will be different implementers supposed to talk to each other mm-hmm so they need to be
- 43:42
standardization of the implementers yeah I see you're just saying this is not enforced by the way the spec it's something they need to figure out right cool now I guess let's talk about how exactly our validators chosen how the sampling happen okay so there's kind of three parts to choosing a relative first you need to have a validator pool which is going to be part of your input we call it actually a registry and you're
- 44:22
going to need a shuffling function which takes the pool and then a seed and then you need a way to generate a seed which is random or close to random and then the the shuffling function will basically permute the registry and then based on the permutation assign roles to the validators so for example if we look at the cross-linked committees you know it will and there's you know a thousand let's say validators but crossing committee then it just takes the first thousand
- 45:02
second thousand four thousand etc of the the shuffle function so there's a little bit of subtlety in which shuffling function you use so specifically we want a shuffling function which is another one a permutation and number two which allows you to in constant time compute where a given index in the registry gets shuffled to and the reason is that it's an optimization for like lines so as a like client I don't want to know the
- 45:35
whole validator set you know there could be a million of them and when I shuffle I don't want to be required to have to to know this information and compute the shuffling over everybody data so instead we want the special shuffling function which allows you to take a single validator and see what they've been assigned to that's a detail the most of the complexity is in the randomness so quick Russian don't Winstead want to
- 46:00
know the the opposite which really data we assigned a specific spot yeah you want to know both yeah so you want to also compute the and we have you know from a few days ago from the the reset workshop at Sanford Dan burn a suggested an a shuffle algorithm called swap or not and it seems to have most of the properties that we want including being able to compute the inverse permutation
- 46:33
and so what is the biggest problem so the most of the subtlety is in is in the randomness and it it turns out that we have a pretty neat solution which is called ran'tao so the idea of randall is that in the in a given epoch the sixty-four proposes that i assigned to the 64 blocks will be invited to reveal a piece of entropy that is local to them and and the piece of entropy is deterministic so they can only the only choice that they have is
- 47:15
able to reveal or not reveal a thing that they are they and only they are meant to know and at the end of the epoch you take all the random reveals and you XOR them and and that's going to be your random number and the idea is that if within a single epoch there's at least one honest participant who reveals the randomness without having communicated it to everyone else then the final random number will be unpredictable from the point of view of everyone else but then we're revealing
- 48:00
them like we cannot also maltiness dividual right so if I rewrite my number and someone else might might see the member ID so we reveal them on the sequential basis so I've got one you know the proposed invite to reveal let's say he does reveal fine then it's not to which is six seconds later you know vitae to reveal he might not reveal and then basically the more you progress
- 48:25
the more you have information about what has been revealed and not revealed and so this kind of points to one of the weakness of Randall which is the very last revealer here they've already seen what has been revealed or not revealed and so they can basically choose between two different completely different random numbers based on whether they reveal not reveal at this very last lot
- 48:51
and and the last ten proposers have a thousand bits or yes if they collude so if within the ten that's one of them that's on this kind of halfway through then that kind of negates everyone who's before them but if you have an attacker who controls the last three then suddenly they can choose basically they have three bits of attack surface so they can choose between eight different
- 49:15
random numbers right so well that's a problem right yes yes and no so it's definitely a problem in terms of having a source of entropy which is unbiased able but it is not a problem if you want your source of randomness to be unpredictable and the bias is limited and so from perspective of validator rotation right so we let's say we're humanists majority we assume that mm-hmm majority of people are honest okay or even more than majority let say to head let's say two thirds and then or let's say that we assume that sufficient
- 50:00
number of people are honest so that if you sample I want you wouldn't need to write because everybody everybody had tests for a book yeah yeah so yeah so we assume the to thought was wanted people are honest then we probably like we do some math and we want to ensure effectively that we want to lower the chance of a particular committee in a short being corrected try to death so we do some math and we get relatively certain that with the given assumption
- 50:33
of the number of honest participants and the given size of the committee that the probability of ever getting a corrupted committee in like you know 10 years is very low so at that point controlling one bit doesn't give you much right because it was already it was already so unlikely that yeah even if you have two attempts mm-hm you still not gonna corrupt the short right right so there's basically three
- 50:57
things going on here there's the there's the assumption that you're making which will be generally like honestly assumption or rationality assumption there's the quality of the randomness which may be you know perfect or possible and then you have the the sampling mechanism which the main parameter is going to be the the size of the committee in as ever consideration such as how how close to ran a random
- 51:31
permutation is your shuffling function but let's assume that it's a perfect permutation then the main parameter here is going to be the size of committee so if we if we have a really bad randomness then you need to compensate in one and I've in at least one of these two things either you need to have a greater honesty assumption which is not great because it means that your your protocol isn't as robust or
- 52:08
you need to increase the size of the committee in which case your protocol is not as performant because now you have more overhead per committee and so one of the things that I've been working to do is to try and make the randomness here essentially perfect so that we can have an optimal assumption and so optimal robustness and optimal performance right and obviously this is a perfect randomness right it's called BLS like two threshold signatures right so why not threshold signatures okay so
- 52:49
there's the generally three key properties and you care about decentralize randomness beacons one is on unpredictable two is on unbiased able and three is the idea of liveness which is that if most of you validators go offline you still want the randomness beacon to progress otherwise you know you might have to stall the blockchain and and that's might that might be something that you don't want the
- 53:17
affinity affinity is BLS scheme has three of these three properties it has unpredictability on many mobility but it doesn't have strong liveness so depending on how many so one of the assumptions that I make is that two-thirds of the validators are honest so one-third are dishonest and so they one way to be dishonest is just to be line and so if even let's say 15% of the illness validators are offline then you get really really close to the 50% threshold that they need for liveness
- 54:00
and so that threshold really has 50% not not 66 to get liveness having 66 but it would be even worse so different is basically assuming that two-thirds are honest and online and that's a very strong assumption but what do you think is an expected number of people who will be applying because if you don't have one-third of online you also cannot finalize blocks right right so one of
- 54:36
the design goals for a theorem is to try and you know survive World War 3 and that's very extreme but there could be cases where you know less extreme things happen and you have half the validators that go offline there could be software bugs you could have a staking pool that goes offline you could have network partitions all sorts of bad things can happen the but then so let's say the staking
- 55:07
pool goes offline yeah then then Kasper effectively goes offline as well mm-hmm yes we will Kasper ever wake up again aha if the if the pool doesn't get back so we have this graceful degradation where even though the financial gadget is no longer operational the chain still progresses because of all MD right because of the lmd yes but then Kasper will never what aha the question is will Kasper ever wake up so pool is gone so let's say them for good it will not it will never come back ok so there's an
- 55:41
atomic bomb that just destroyed the whole continent I'd say yes yeah and these people will never come back online so what we have is the mechanism called an activity penalty so if you don't show up for extended periods of time then your your balance starts eroding and once you reach 16 F which is half of the 32 if that you need to register your forcefully ejected from the valid data
- 56:09
set so you have the LM d ghost that progresses with those who are online and the the balance of those that are online will will stay roughly constant with those who are offline will decay and so eventually those who are online will be able to become the two feds that are required for Casper to progress and if I see two inconsistent justified blocks what does the fortress rule then so you
- 56:41
you build on the the highest justified block highest in terms of D in terms of the epic number so could the following happen let's say I'm a validator mm-hmm I'm the one that use honest validator everybody else is perfectly honest and I I just keep on creating blocks right so each block has exactly one signature and I do it for a year and through the graceful decay everybody else in my
- 57:12
chain mm-hmm is kicked out yes so at some point I'm actually the only validator but I'm most of 100% of validators mm-hmm at which point I can start doing Casper justified blocks in my chain mm-hmm and all I need is to create a Casper justified block in the 4a epoch higher and and naturally my blocks will be justified faster yes like I can justify the block immediately like the very first slot my previous block is justified right or like I guess to
- 57:42
before justified looking at one on top of it right mm-hmm so wouldn't for cheese roll choose my block naturally because it's for a higher for a higher epoch no that's good so the reason is that you know you have you have the great majority of people who are going here and then suddenly you've decided to fall off as an individual well the great majority is going to continue thinking that but but but but will their software
- 58:21
not pick up on my on my blog like is the client smart enough to not say oh look at this this block has is a justified blog by Casper for a higher ebook number I will continue building on that and then the next thing you know is that you know six seconds later every single validator produces a block on top of it mm-hmm so we have certain guarantees in terms of how much the validator pool
- 58:48
changes so for example we have a cap on the churn of in terms of validators that come in and that come out and so that means that roughly speaking on the short to medium term you you have a relatively well defined notion of who's a validator and so you can apply weighting on a on a nice short to medium term basis oh yeah you said you're saying like it will be applied to deter actively so what happens when the client sees both chains well the thing is that this guy will
- 59:32
only be able to to finalize blocks in his like solo chain after let's say four months but for four months is is it's too too long a period like the the chain will will have finalized here independently so there's like some sort of a check point which is even stronger than Casper right so we have this so that there's two types of nodes right there's the the like clients and the four nodes the four nodes that are
- 1:00:15
regularly online they this this chain will will just have no weight and they'll just continue here I guess okay this is your answer so the the thing is that the the the weighting of the lmd ghost is based on on the the validator registry at this point in time so so here so the way that the way that the LMG goes works is that you start at Genesis and then you move forward and any time you have a branching point you select the heaviest
- 1:00:56
that's the way it's defined and so here you want to select the heaviest based on the validator set at this point but you own the doll and it goes from the last Casper Casper justified block right mm-hmm so with the time we hear for months in the future there's some so the chain we were building all of us has some latest justified look like somewhere here and then the fake chain but also later it's justified relative to this relates it to the validator registry here so here it
- 1:01:28
alright well it wouldn't be counted as justified right by that logic on the on the main chain so let's say there is no fork right let's say there's a nuclear winter and so people naturally get kicked out from the validator pool then again we cannot justify blocks right because like how can we how can you distinguish two cases one were one third of people maliciously worked out in the past and one word two thirds of people actually are extinct right what do to
- 1:02:08
software bugs alright or some other reason right so already so effectively so let's say that this chain doesn't so first of all let's say it's not one person it's actually like 25% of people and it could be that either everybody who's left or or it's or it's a malicious fork and and so now two scenarios Watson there is a that is the actual chain that's the chain that is being built and this one does not exist in principle in which case cars produced to finalize blocks right at some point
- 1:02:40
mm-hmm so I guess I mean that's an interesting question I guess the the chain that has the most liveness so let's say this one has only one guy and this one has you know 25% will will justify first when you read me me but I think this is probable like you can have snapshots every two months right sort of stored on the italics github and everybody agrees on them I mean you could have a rule which says that if there's been no
- 1:03:17
justification for for two months then you know LMG goes starts taking precedence over the finality in perpetuity no but at least you you'll stick to this chain you won't you won't just suddenly are you saying when you choose between two different chains yes if you have code justifications but they but their common ancestor is as long ago then you have no ring justifications and
- 1:03:48
using LMD right yeah that's an interesting edge case I guess we need to work specify in the spec awesome what are the interesting parts of the thing we didn't cover yet so I guess we we didn't talk too much about the state layer in the shot yeah so I guess the EVM 2.0 which will be the new virtual machine will be very very different from if you're the VM 1.0 so it will be based on web assembly which
- 1:04:32
seems to be a standard that many block chains are using it will have things like sustainable storage so in the film 1.0 the dynamic is that the state grows linearly over time and that's that's not very sustainable and the reason it's even less sustainable and if you're 2.0 is that the chart committees will so basically these are people who are meant to extend the blockchain if it's shot over it's a period of weeks they will be
- 1:05:14
shuffled from one shot to another over time and every time they're shuffled they need to download the state of that shot to sync up and so they are only given a certain amount of look ahead to to shuffle so let's say they have they have one day to sync up but it's possible that at some point in the future one day is not even sufficient to sync up to your new shot and so that's why we want to have a sustainable storage model and one one way of doing that is simply whenever you own a piece
- 1:05:46
of storage you meant to pay for it on a regular basis and if you don't pay then you lose that storage slot answer an example of your seat when it working is it going to be the contract owner who pays for the storage of my account or is it going to be me so I guess that's going to be an information implementation detail for the app designer but I guess both could work depending on whether or not there's some sort of
- 1:06:19
central coordinator who who has an incentive to subsidize basically storage for everyone else so for example the in the case of crypto Kitty's right you have you have these these these tokens which are owned by individuals but at the same time you have some sort of that operator who has some sort of financial incentive to have the whole thing running so they want to simplify things
- 1:06:41
for users they can just subsidize it and the fully decentralized module where everyone's on their own what will happen is that most likely the user will have to pay for it but that's not necessarily a big deal and the reason is that if they don't pay for their storage slot then the storage slot gets cancelled it gets removed but you still have a cryptographic trace that this storage
- 1:07:07
law did exist in the past so you still have the route and you can still provide witnesses and so at some point in the future assuming that you've you've remembered that you have that you own this and you know where it was then you can revive your token and you can spend it right but that assumes just so that like clearly this is needed without that blockchain like long term no mm-hm blockchain can can probably exist but it has a lot of interesting problems one of them is Quantic development becomes way
- 1:07:41
more complex if you actually don't plan to pay for users if you plan to pay for users it's nothing changes right I mean you can do the same way but now if you don't want to pay for users your contract needs to be prepared the data will be gone mm-hmm right and moreover so it's pretty common on the theory on for people to have proxy contracts right so that they can have the upgrade in the future so if you upgrade lets you have
- 1:08:05
some sort of code which changes the way state is stored like you used to start storing JSON you realize that super inefficient so now you want to store it in the binary format and then suddenly one of the all users comes and says oh I want to revive my state right so it's it's all like there's a lot of layers of extra complexity enough for the the app developer so one kind of interesting design space is what I call States minimized
- 1:08:34
decentralized applications so where you don't necessarily require state or a lot of states and there are mechanisms where all the state that a single that requires is just a hash it would be like a miracle route and users have to prove their state that like a stateless approach yes that's one way I mean you can also think of of plasma as being fitting within this design space yeah
- 1:09:09
there's there is quite a design space where you you don't actually use the state like a lot of the power of block chains turns out to be to lie in the data availability layer like the execution layer is mostly a convenient thing like you can have what I call alternative execution engines which don't require any state whatsoever at least no no notion of enshrined state so let's imagine that in in in the shards there's no EVM whatsoever there's only
- 1:09:47
there's only data well you can still have an execution engine such as true bit so the the way that trooper works is that you make transactions but you and instead of running the transaction through the EVM some sort of naive execution what you do is that you say just don't execute it just put it on the blockchain and for each transaction you have a crypto economic commitment that
- 1:10:23
the the corresponding state change will be this are you going from this state route to the state route and if someone wants to challenge you then they can do that with an interactive game which is very cheap but in the in the default case is not your advantage to put the the wrong answer because you will be caught and you'll lose a lot of money and and people who use blockchain
- 1:10:54
they don't need to relegate transactions they only need to validate the those games effectively right so that's like a really nice model because if if as a user I only care about you know a specific gap then I only have to execute the transactions in that gap and I can ignore everything else I can kind of be a full node for my DAP and so one one thing that you can do is that you can have the the challenge game for true--but live in if you're in 1.0 and you can use 2.0 for all your
- 1:11:32
transactions with no EVM and that would still be a scalable execution model unless unless you submit like invalid transaction or shards and then all I guess they gave the game the game doesn't have to happen quickly right right it doesn't necessarily have to happen quickly but another execution model which which doesn't require state here would be to use snark source not Starks so all the data goes in the
- 1:12:04
shards and then the only thing you put on 1.0 is a stock every time you want to put make a state change yeah it's not as much would be awesome mm-hmm 1d fast so for for the vm 2.0 is the language is it will solidity compile to the new virtual machine like how much extra work will it be for people who have contracts on the thing 1.0 to transition right so very likely you know someone in the community will make the
- 1:12:34
effort of having solidity compile to tourism and one of the nice things of wisdom is that you really have a vibrant ecosystem and lots of tooling and so you can make use of that but I guess from the point of view of application developer you don't really care about the individual instructions you only care about the more high level code so one of the big so that I guess there's
- 1:13:04
the several changes from the point of view of an application developer so in terms of good news you're gonna have more scalability so the the transactions fees will be lower you also have faster block times and more consistent block times instead of having the Poisson distribution that you have a proof of work in terms of the bad news one you're gonna have storage went and two you're gonna have crushed all
- 1:13:36
communication all right and so now every time I want to depend in another contract I can never assume that the contact will be on the same charge rate or rather like do I have the control over where my contract ends up being yeah you have full control so when you launch the app you want to make sure that at the time of launch it's kind of optimal choice in terms of avid apps you
- 1:14:02
want to interact with you want to try and maximize the avid apps that are useful to your dab you might also choose your shot based on the gas market so another complexity is that every shot will have a different gas market so you know if you have a really successful that point on one shot that will push the price up and so that will be a kind of a natural incentive for people to be able to to move dead apps to have a shot
- 1:14:34
so one of the design space that we're exploring is the idea of ranking which is basically a way to take a DAP in one shot and put it into another shot yeah that would be that was my next question and that's separate from yanking which is the way to do synchronous cross short calls right there's this old idea of like let's say you want to it is to solve a train and a hotel problem where
- 1:15:00
you're looking the trend but you also see yanking it to the hotel coin shard so that the rest of the execution you can actually only see on the single shard oh I see mm-hm it was posted on III search so you want to use yanking to do this so basically the problem is that across shots you have a synchronicity but we've been assured you have synchronicity so I guess the idea is that step one you put all the shards all the contracts in the same shot and then you execute synchronously within that and then you put them back out first of
- 1:15:30
all stop my dates I think it was italics I'm not sure who posted it but the idea was not to bring the entire state of another contract that would be extreme uh-huh the idea was that if you have you want to do some synchronous operation on to like let's say two entities like two small parts of the storage in two different contracts the different shards and so one way naive way to do that would be you lock you have to look at effectively you'll work it on one shard and then you do a series of crossword
- 1:16:00
communications if you like to do the actual execution because you need to check availability on both then let's say you need to put them both on hold a couple more steps and that would require a synchronous communication every single time while instead as you lock the object like let's say I'm working a particular train ticket I'm mostly yanking just that little part of the state right to another shard do everything in a single shard because it's locked
- 1:16:23
no but you can change it to check if I'm processing it here and then I'm sending it back with some sort of evidence mm-hmm that it was done properly but it's also called yanking right so I guess I mean even though you've managed atomicity with the synchronicity you still have to pay the cost of a synchronicity because you have to do yanking itself is I think right yes yep okay actually one question which is unrelated to the to the short chains is
- 1:16:56
when I post 32 Eve on the e3 1.0 chain mm-hmm ethereal 2.0 chain will wait for some number of blocks right before before honoring my mistake right mm-hmm then let's say that something very bad happened and the history was rewritten even after many many blogs will will rule the 2.0 chain also fork out yes okay so that's you know one way to attack the 2.0 chain is to attack the 1.0 chain and but that's is there a plan
- 1:17:36
at some point to remove that link yes so it's kind of a multi-stage I guess roadmap one one intermediate stage would be to try and provide greater security to 1.0 to kind of have a tighter coupling of the security between the two and one way to do that which is quite neat is that you you change the focus rule of the if you're in one chain to take into account finalization in the 2.0 chain so the way the way that this
- 1:18:13
links work works in practice is that you have these if you're am 11.0 voting periods in here where you have let's say a thousand validators in the period and they're going to be voting on a recent block root block hash from here and if you meet the threshold to say two-thirds then then all the deposits up to that block hash will be processed and I guess what we could do is we could take this
- 1:18:51
block hash and finalize the if you're 1.0 chain from from there before once the film 2.0 chain is finalized the main complexity here is that every single if you're 1.0 chain now needs to be aware of the 2.0 chain now that's not necessarily a problem for the full nodes because being a full node of the beacon chain is not that expensive but it is a problem for light clients because if you're one point of light clients you know they can be running in your phone or whatever so we need to have
- 1:19:25
like client protocol implemented 42.0 before we can even start doing that so my guess is that it would it will take some time before we have the infrastructure necessary to start finalizing the OneNote chain using 2.0 but isn't that the concern that one's 2.0 launches and it's fully operational the the incentive to mine on 1.0 will be slowly decreasing right because like for example transaction fees are going to be going down because contracts are moving to to the to the chain to the to the
- 1:20:03
short chain possibly and so the the security of the 1.0 might might start degrading so I guess most of the security is not for the transaction fees is from the the going basis the main thing and I guess a lot of the security comes the 100 chain comes from how valuable if is and the eve here and the eve here should be roughly the same thing and for the time being while the link exists there are going to be two independent sort of minting authorities right because one point is still meeting
- 1:20:43
the same to either block or say I don't remember if that happened and then 2.0 will be meeting for for the validators right mm-hmm so I mean the 1.0 chain is like really inefficient is like an old car as burning tons of gas and is being one expensive standard expensive to the owner but also you know expensive for the planet and you know you might have inflation on the order of you know 5% 10% per year here the inflation will be
- 1:21:16
on the order of you know half a percent less than 1% so one of the once we have the 2.0 chain providing security for the 1.0 chain we can reduce the the minting in the 1.0 chain you know by a factor of 10 or or 20 so if we do reduce it by a factor of 20 then we basically go down to the roughly to the security of an FM classic so if M classics proof-of-work security is it's not perfect because we've seen
- 1:21:48
there was this 51% attack but it's still you know good enough on a short-term basis and I guess with the 2.0 chain would provide is that it would provide frequent finality so you could do 51% attack but only up to the last finalize point so the you only basically using proof of work for reasonably convergent progression of the blockchain not for its security and once the link is removed is ether that is still nothing
- 1:22:20
one point or gone or like I will always be able to transfer it or or I guess if the link is gone there is no - they cannot transfer it possibly right so I think at this point it's very likely that 1.0 chain will live for very long time like on the order of decades and there's there's two models where this this is sustainable model number one we basically include 1.0 as a contract within one of the shards in 2.0 so this
- 1:22:51
is kind of in theory possible but in practice possibly quite difficult or at least not worth the effort the much simpler solution is just to have very many more or no minting whatsoever of new Eve in 1.0 and just rely on the security of 2.0 and just leave this chain as it is right we're almost running out of time let's spend a couple minutes talking about cross our transactions because I think that's pretty interesting topic mm-hmm so in
- 1:23:25
order to initiate the cross card transaction or like in general how does it works if the transaction wants to a synchronously call another transaction mm-hmm how is it how is it going to look from the perspective of the contract and and how is it like roughly work how the traffic work so one thing to mention is that crusher communication is not like a thing it's more of a design space it's a bit like plasma you know there's a reason one plasma energy you have a lot of
- 1:23:55
options as to how you do your your communication it's not going to be hard-coded in the protocol well in practice at the application layer you'll have tons of option and you'll be able to rely upon very basic infrastructure at the consensus layer and it's possible that the more we progress the more fancy the infrastructure will provide but I guess let's we can talk about the basic
- 1:24:21
infrastructure that we will provide so we have we had a very short here and we have the the beacon chain and the shards include these cross links which get finalized eventually and so if you if you want to make a call from here to here at the most basic level at the consensus layer what you do is that you'd in ribbon each shard you'd have like a special address which would where
- 1:24:59
you could basically take some ether and burn it and in the process of burning it you will generate a witness and then once the the cross link has been seen by the the destination shot and that crossing has been finalized then you can take that witness and you can consume it in that other shot I see now the question is the most interesting question of cross card transactions is
- 1:25:35
what happens if we end up actually having one short corrupted and they and they finalize a cross link which of an invalid block so the questions here first one is is there a procedure to revert the cross link in the future or is the short chain doomed token to to keep on building on top of that invalid lobe for life and the second is if the if some other shirt builds something depending on that cross link will they get river to think okay so if one of the shards somehow manages to cross link
- 1:26:10
either unavailable data or invalid data then that's very bad and that can pollute the whole system so if we do have one of these failures which in theory should not happen but they might happen in practice if the assumptions are not met then we will basically have to roll back to the previous known good state in that particular shirt in the whole system in the whole system yes I
- 1:26:39
see now there's two ways to roll back the the the best way is to roll back automatically and it turns out that you can do that for data availability and the reason is that even though the beacon chain might not be aware that some cross link is unavailable the the clients they know about it kind of subjectively and so you can have an enforcement of the rule that cross links need to be available be done at the
- 1:27:15
client level not at the you know not at the beacon chain level and so the clients themselves will exactly yeah and so the idea that we're exploring here is using a range of coding so that you can have very good probabilistic guarantees that with very little bandwidth so let's say the the you want to check that you know 100 megabytes of data is available instead of one dumb way of doing that is
- 1:27:47
just to download the 100 megabytes but you can use the racial coding and statistical methods to basically download let's say only 1% of that one megabyte and have very strong guarantee is that the 100 megabyte is indeed available and that's the front crowd proofs paper right yes exactly yes okay I think I think we have to finish here okay yeah the room is only ours until now okay so thanks for coming and thank you explaining with
- 1:28:18
you