Casper cbc / Sharding - Vlad Zamfir

we don't have correction Casper and sharding you can talk yeah so didn't plan presentation or anything because I thought I would do an anime on the record section Casper and that's kind of like a technical conversation about consensus and about specifically this constants for thought that I've been working on I published a paper on and I'm still you know working on publishing more and more information about so this is like a opportunity for you guys to get some free publication information or some information to clarify the publication stuff but if and if no one has any questions right off the opening I could I can I can give the basic basic outline of the safety proof that all of the consensus protocols in the correct by construction family are derived satisfying so III would like to do that if no one has any objection so but I see a question yeah oh yeah sure so hi I'm glad Dampier I'm a researcher Darian research slash like aetherium Foundation I work on consensus protocols and proof of stake predominantly I have a few side projects but that's pretty what I work on is consensus protocol is a proof stake I guess I'm like a consensus protocol engineer so the nice thing about all this correct by construction protocols is that they all satisfy the same safety proof and that the safety proof is really kind of simple I have I can I can show you the basic shape of the safety proof we have well basically we're gonna consider this this kind of structure where we have objects called protocol states and morphisms between them called protocol state transitions and you know if you if there's a transition from one object to another then there's also going to be a transition from if there's a transition from one to the other to a from that one to a third then there's also gonna be a transition from the first and third so basically I'm saying oh look there's a category of state transit State protocol States and protocol state transitions and then there's gonna be a map from protocol States to statements about the consensus called the estimator so there's this thing called the estimator that Maps these protocol states which I'm going to denote like this two propositions propositions about oops propositions about the state of the consensus so this would be something like oh this consensus is zero the consensus is one oh the block at this height has this hash the block and this height has that hash so kind of a proposition about the consensus about the value of the consensus so you can think of it as straight-up oh here is the value or also as something a little weaker like Oh the value has this property to the east of the edge to the estimator is this kind of theoretical kind of map that Maps protocol states to propositions about the consensus so and this is like where this is like the fork choice rule for example which Maps set two blocks to a single block chain which is kind of like the value of the consensus that you that you kind of art guessing so this represents basically guesses for the values of the consensus that a node would make on any given protocol state and then basically uh that's it basically have this definition of safety basically that some proposition is safe at some protocol state kind of if and only if for basically for any protocol state that you can evolve to that property also holds for that state so basically if we have the property hold for every protocol state in the future then that's somehow called safe so a value of the estimator or something that the SD estimator kind of implies is safe if for any future protocol state that that value holds so if this block if this block has this hash as a block of height ten has this hash at this protocol state and at all future protocol states then we call that block safe or that's this per we call the proposition of this block at this high it has this hash safe and then basically you know by the way also that every there's a proto there's a state transition from every state to itself so so I didn't say that this thing also satisfies it because well if all future states satisfied and ever for every protocol stage of the future state of itself then then I'll kind of get over free okay so now we gotta kind of are going to get to the safety proof the kind of key part well so there's one so imagine we have imagine we have some protocol state here where we have some state proposition P then well we have this this lemma that basically says that oh look if there's some other protocol state here Sigma hat then this is also going to be safe because well if something is invariant for all future states then it's gonna be invariant for all future states over future states because future states of future states are also future states and so so you can show pretty easily that if if some proposition P is safe at this state then it's also gonna be safe there and then now imagine that we have this other it will call this a sigma wanna Julie and now imagine we have this other state sigma2 here that also evolves to Sigma prime then we're gonna have the kind of following property that we're not safe on the negation of P because if we were safe on the negation of P then we would also be safe on the negation of P there and but actually because of a property of this guy that I haven't talked about it's impossible to be safe on P and on the negation of P at the same state that's kind of intuitive because you can't even have both P and not P hold for any states it can't be the case that both P and not P is safe for any state and so basically if this guy is safe here on P then then then Sigma 2 here is must must be not safe on not P and so just from the safe on P at Sigma 1 here so basically we had like I first Dovie all we really knew is that we had 2 protocol states Sigma 1 Sigma 2 with a common future protocol state Sigma Prime and what this kind of meant was that Oh safety here means safety there which means that we don't have we don't have safety on the negation of P here so this means that safety on P at Sigma one implies not safe and not P Sigma 2 and then by kind of just like a little bit of algebra this means not this guy or this guy this is just a normal kind of like Oh getting I don't remember the name of the world but you just get rid of the implication and then by demorgan's rule we get not safe P Sigma 1 and safe not P Sigma 2 so this this this conclusion here is exactly is is exactly consensus safety it basically says that oh look we don't have safety on P and safety on not P at state Sigma 1 and Sigma 2 so it turns out that this statement here that safety P implies safety not the absence of safety unknot P and Sigma 2 if Sigma 1 and Sigma 2 you have a common protocol future it's the same as Sigma 1 and Sigma that decisions on safe P and or more specifically he says that P and not P are not both safe at Sigma 1 and Sigma 2 respectively so basically it's not the so basically all of these protocols are gonna work on the following kind of premise we're only gonna make decisions on safe values should maybe mention that earlier all the decisions then it says protocols are gonna make are gonna be on the safe values and so the decisions are gonna be consensus safe for any two protocol states they have a common protocol future by kind of this argument that says that oh if they have a common protocol feature then it's not the case that they're safe on some proposition and it's negation so somehow this is like the basic shape of the safety proof and then the next part is basically to guarantee that notes have a common protocol future as long as there's less than some number of Byzantine faults and so basically as if we have a common protocol feature then we have consensus safety is kind of this part of the proof that are shared with you you know for decisions on safe estimates and then the kind of part that I didn't share in the next part which if you don't stop me I'll go to is that nodes have a comment you kind of we make constructed so that knows how I'm a common protocol feature as long as there's less than some number of Byzantine faults so I guess now I'm gonna pause and see how much I've lost you so we have protocol States protocol state transitions an estimator that Maps protocol states to propositions about the consensus definition of safety that says oh look some proposition is invariant and all future protocol states we have this notion that oh if P's safe signal one and there's a transition from Sigma to Sigma Sigma 1 to Sigma 1 prime then it's also gonna be safe there which additionally means that for anything that transitions to that you're not gonna be safe on its negation because then you'd have to be safe on both P and not P here is impossible and then this kind of gives us a kind of distributed consensus a distributed safety for any protocol states that share a protocol state in common so if you and I are - protocol states we share a protocol state in common then any decisions we make on things that are invariant it over our futures have to be consistent because we share this protocol state in common where we could both end up and where all the things that are safe for each of us would both be true so that's the basic basic set up for all these protocols and then things that vary between them are Oh what are actually our protocol states what are what is this estimator map but in terms of the basic consider the safety proof the basic setup and all remains unchanged which is which is why it's pretty cool one of the cool and also like why we generate generate because it's a protocols and make changes to them without changing the proof a lot or at all and that ends up being released for because you don't have to lose or we have to reprove properties of your protocol as you iterate so yeah please why this is what you're actually tweeting advice to some thought okay what am I actually doing and why is this important okay so so basically what what I'm what I'm describing is a proof about certain protocols consensus protocol specifically that it in but when I'm what I'm doing is basically set a setting up a process for generating consensus protocols and I could share with you some considers protocols that are going to satisfy this proof and then what and if you believe that consensus protocols are useful then you might think of this is useful so and I said it's a protocol I could make at that pitch to is useful for making reliable processes out of unreliable processes it's it's they're they're good for if you want fault tolerance in the execution of computation especially if you have non commutative operations [Music] they're pretty they're they're they're a really great hammer and distributed systems that really kind of provide a really really strong guarantee of replication and and and they they make it easy to reason about how to do a lot of a lot of stuff because you don't think if you have consensus protocol is you don't need to think in a distributed fashion as much when you're designing decentralized systems because yes the question is about what about the long-range attacking you know isn't it the issue that like old states are not safe anymore well I think it's kind of important to note that the long-range attack is really uh it's a economic problem more than like a peer consensus protocol design problem it's it's an issue to do with the fact that nodes that are unbonded are not incentivized to not double spend and therefore can Mabel be very cheap for them to do that and so we would expect the Byzantine fault tolerance of rates to be much higher for old from old states than from newer states by this kind of reasoning and that's you know doesn't really factor into this because this is kind of like not the economic story but let me say that when something is safe here that we're talking about a kind of local notion of safety that a node will never have will never achieve a protocol state that doesn't have something it we're not talking about consensus safety except for in the context of this kind of distributed safety proof so so so the the interesting thing about this is that it bridges the gap between a local notion of safety or like an invariance and a distributed one when you have more than someone ever Byzantine faults as we might see or as you know it turns out you can't have consensus safety even though you might have local safety so it turns out to be impossible to build the protocol that will guarantee that two nodes have a common future protocol state that also has this proof hold it in the context of a hundred percent Byzantine faults and is it also non-trivial meaning that it can have it can actually decide are two inconsistent values so if you have a protocol that never decides on anything then you can satisfy this quite easily because you can always have common for teacher protocol states if you never make any irreversible decisions it's the kind of irreversible decisions that make two possible protocol states not not share short not share protocol features so what ends up happening in some kind of consensus protocols is at some point nodes will make will kind of get will be vibe by valent and at some point they're gonna be completely committed on a value and it's possible with a hundred cent Byzantine faults that knows will end up in OneNote up here and one other there here they'll be safe on zero here they'll be safe on one but they don't have a consensus safety right and so really when you're talking about the language of talk problem you're not talking about the local safety issues local safety stuff is just fine talking about the consensus failure meaning a lack of distributed safety due to an increased number of Byzantine faults which is something that totally fits perfectly well in this framework but this framework does nothing to guarantee the unexist ins of Byzantine vaults that's more in the kind of economics and mmm governance kind of like validator got a management layers so for now I'm just talking about like much more base level kind of consensus protocol shenanigans [Applause] personally have a small ring work 15 ounces for the economics well so I mean there's so one thing is the protocol design and other is the analysis and and and and to some extent we know there are limits to our analysis that we're not gonna be able to capture in our protocol design but you know we do have models and basically at the end of the day I think the foundational example is you have a smart contract and it wants to pay Alice to send a message to Bob or penalize them if it doesn't happen but if Alice fails to send the message or Bob fails to send the proof that Bob receives the message then the contract doesn't know whose fault it is and so somehow we have like a trade-off right if the if the contract penalized is more like fewer Alice's and Bob's will show up to play the message passing game because it's more unfair for any given person perceived rate of Byzantine Bob's Alice will have a lower return if the Byzantine rate is higher and so I you know the the thing that the simplest thing to think about is okay let's have a situation where we have a bunch of people showing up to set send messages to each other just like in a really like direct and simple way rather than in a concerns the protocol and and think about okay what is the amount of participation for a given level of for a given utility function for a given level of perceived Byzantine faults for a given background rate of interest and like how many deposits will show up and then and then and then think about okay as an attacker attacks and increases people's perceived rate of Byzantine faults how fast is participation fall and because basically the fundamentally the fundamental kind of most effective attack in any of these protocols is first to discourage participation and then to commit the intended faults because the fewer deposits there are the easier it is to attack and so like this this kind of game where anyone can show up to play the Alice sends a message to Bob game is I think the simplest example having able think of with all of the same kind of challenging economic features as the problem of incentivizing extensive vertical but kind of more broadly about incentivizing consensus the first thing to think about is okay well we want to incentivize people to follow a particular protocol assuming that we solved the problem of consensus and then so we need to be able to detect people's behavior detect the deviations from that protocol and penalize those but specifically what we want to do is penalize the ones that cause a degradation to the to the quality of the protocol so imagine that there is a failure and there are some Byzantine faults and some of those Byzantine faults caused the failure and some of them didn't the ones that caused the failure are somewhat much more culpable and those are the ones that if you penalized you actually make a cost of failure much higher but if you penalize people for any Byzantine faults whether or not they cause a failure then you increase the risk that someone will be penalized just to faulty hardware and software and that decreases participation and reduces security and so this is kind of we need the protocol needs to infer the participants behavior penalize only Byzantine behavior like truly malicious behavior in order to not penalize honest behavior and in order to like try to maximize the cost of attack my philosophy is very much like maximize the cost of attack first and I try to do that inside like tractable models because things can blow up quick I mean even quadratic utility it turns out to be really hard to parameterize these things but I feel like we're getting some for somewhat districts oh so we have this economics threat and this is distributed systems thread I guess you know next question or I can pick the choose-your-own-adventure you know anyone so so is different than customers then the customer friendly finality gadget which is the kind of protocol of italics working on which is kind of an overlay on top of work that finalizes it checkpoints sorry the question is how can I compare this to the finality gadget and do I plan on proving the safety the finality guide in this framework and I've kind of I have thought about that right like letting the protocol states of the finality gadget be the protocol states in here and having an estimator and it definitely seems to seems to work but the the the the reason why this proof is is so nice it turns out in the end isn't because we can show that nodes have a common protocol future as long as they have less than seven hour Byzantine faults it's the way that we show that the way they're kind of construct a really like simple way to make it happen and where I was like to prove that for the finality gadget basically will require that I run through the finality gadget safety proof as far as I can tell so I can I can I can kind of in a way that like just uses vitalik safety proof prove it in this framework but I don't know that I can prove it in this framework kind of natively right so I guess I guess that is a good kind of transition to talk about like how I make sure that noes have common protocol features as long as there's less than seven over Byzantine bolts it's pretty simple pretty pretty pretty pretty awesome even so imagine that we were just have what so imagine we were just to have protocol states that were set you set sets and protocol state transitions that were super sets so that we have this lattice or basically you know you have like a be a union B and you know eventually we have like the empty set down here so if basically if protocol states were per were sets of protocol messages and state transitions were receiving a protocol message and two notes can always send messages to each other then we would have this pretty pretty trivially guaranteeing that nodes always have a common future for a goal state because well it's a if I if my protocol state is a where a is like a set of messages and your protocol state is B well then we have a common protocol state in future called a union B and this is great because like oh look we guarantee do we have common future protocol states which mean that we have consensus safety right but unfortunately because every two states have common future protocol states we never end up with in an event like this or nodes like don't have a common feature protocol state which is X is like specifically what you need for non-trivial T right you need to make inconsistent irreversible decisions so we're gonna do is kind of this right we're gonna say okay we're gonna do this but any any protocol states that have more than some number of Byzantine faults we're just gonna delete so if the if a and B has more than some number of faults it's the fault count a and B is more than T some threshold we just delete delete' that state how exactly we do we figure out the fall count from set of messages maybe talk about it talked about a little bit but with this set up now we have okay no two notes have a common future protocol state so no receiving mess having seen message a and in others a noticing you have missed messages B have a carbon future Oh state as long as a and B has less than similar faults meaning that they don't have a beautiful future protocol state when there isn't that when the Union doesn't have that number of faults and and that kind of is the construction basically nodes have a common feature protocol state as long as they in the Union of the reviews don't exhibit some presenting false because protocol states are are sets of messages and they can transition to the union other views as long as their that is the protocol state and it will do as long as it has less than summer Byzantine Falls and so and so the the the the setup is basically relying on this idea that we can do Byzantine fault detection from sets of protocol messages and it turns out we can but but I all pause for questions first so but first I guess a let me do an overview so okay it would be great if we just made protocol states sets of messages and allowed any two protocol states have a comment feature by looking at the union of those messages because then we just have consensus safety for everything but we can't do that because that that would have we would have triviality because any two states that have common future protocol states which means that no two no state has ever made any kind of your irreversible decision understand of any any consequence and so and we can end it and we can kind of give ourselves the this possibility of having two states that don't have common future protocol States by simply deleting all of the know all of the states that exhibit more than some number Byzantine faults so here here is like a maybe it may be a story so this is this is a let's call this a set of messages a and this is set of messages B and they an ending and they have some intersection right and these these paths represent sequences of messages from from validator so this is like a validator making a bunch of messages and some of those messages are in the intersection and some of them are not so this validator here so all these about all these validators are honest but the validator a doesn't see those messages and validator B doesn't see this message but there's gonna be one validator here oh that there and then and there and they kind of equivocate in a way that like a and B both seem they both seem to be honest and B but in the union of their views you can you can detect that this this validator has equivocated so in this case base assuming that default are special to zero a wouldn't be B wouldn't be able to receive these messages from a and would therefore he wouldn't be able to transition to this common protocol state a union B and similarly a wouldn't be able to see these messages from B and wouldn't transition to this state a union B and instead it would be said they would instead not share a common fear protocol future but if their but if this Byzantine fault wasn't there they would share a common protocol future because their Byzantine fault detector wouldn't stop them from going there so yeah please please please ask me questions I feel like I feel like I'm not doing any communication here I mean relative to proof-of-work you mean or like okay yeah so I mean so the cool thing about this setup is that we can we can we it turns out that like for example in Casper the Friendly Ghost we can finalize blocks like you know in in in the sense of like a synchronous Byzantine fault-tolerant protocols with the same network overhead as Nakamoto consensus and also when we produce blocks they really just don't having to have a signature and so we're you know we're talking about a no increase in network overhead over Nakamoto consensus and also you know a dramatic reduction that costs of producing blocks constant verifying blocks this a little bit higher because you need to check a hash and a signature rather than just a hash although some hashes are pretty hard to do so you never know [Music] so basically the hmm yeah so so yeah I kind of lost the listener here basically when I was talking about the state transitions and why these stages is like would or wouldn't be allowed even though the state transition is meant to be like the superset relation it's basically only the superset relation from sets of messages to other sets of messages that don't exhibit too many Byzantine thoughts so in this case or really it's only a state like the yeah so so so in this case the state transition from B to B Union a would introduce a Byzantine fault that wasn't observed and just B and and so and so that's kind of the story there the story is that like okay well a is a protocol state and B is the protocol state but a union B are not because a union B exhibit too many Byzantine faults that's what it's kinda like there were too many publications between for a never reconciled yeah kinds of faults really there's invalid messages and equivocations these are thoughts that aren't distinguished that aren't indistinguishable from network latency so there are these faults called liveness faults which are distinguishable from that aren't just sitting there or latency and liveness faults can't cause safety failures and asynchronously safe consensus protocols so in an asynchronously safe protocol liveness faults don't cause because as his failures and life as faults are indistinguishable from Network latency right so there's only folks that aren't indistinguishable from Network latency that could be it could occur really and then those basically look like well they it's something's indistinguishable from network latency if it's the result of a different resolution of race conditions and so anything that custody was like ordering messages and ordering messages and timeouts it doesn't count and so basically you basically any way that you can run the protocol in a valid way like is like the way that you can run the protocol with just liveness faults you know valid but asynchronous rights valid in any possible coordination and so the there's invalidate there's two ways to run the protocol an invalid way one of them is to do an invalid state transition to let go to like it go from like a state to another state where you work or and the only way that would be evidenced is with an invalid protocol message more with basically so so through through through the like messages that you see from from a node they're gonna evidence there having been a different protocol States and unless all of those have a state transition a protocol state transitions through them then you can't tell then it's not plausibly business closed and be honest so for example if I have a protocol no that's exhibited this state and in this state well there is no single state transition through those and so that's an invalid way to havoc there's no valid way to I've executed that protocol and this is one equipped looks like an equivocation kind of looks like oh there's no way for you to have as a single threaded protocol execution hit both those points and so instead we speculate that oh you you must have run the protocol more than once or run on modified versions of protocol so basically as long as the evidence that they produce could have been produced by us a protocol execution then it's that it's that it's not like couldn't have caused us a safety failure and the safety failures basically are gonna be caused by things that can't be called protocol executions so it basically pronounced to invalid messages invalid Protocol transitions and running multiple versions of the protocol so an invalid transition will just jump randomly and running multiple versions of the protocol will let you kind of go only valid transitions but to get to get to do two different valid locations and you know with the path that couldn't have been well in a way that would have been impossible to do with a single path of the protocol yeah that's not a safety problem that's a lioness problem so the court so the reservations are you can still withhold messages and yeah you can but those those don't actually factor into the safety safety considerations they're only really liveness there's a live yes it's called so the question is do I see a use case where T is greater than zero and the answer is like yes well any small tolerance we really want to have more than zero tolerance normally and so that's a TIA teens that Byzantine fault tolerance kind of number people normally like to have a number like a third but uh that's that's or Tia's yeah so so you know it's definitely kind of important to be able to maintain protocol features with someone in the context context of a couple of Byzantine faults it's impossible to maintain common feature protocol States them in the context of a hundred Byzantine faults if you're going to be making any kind of final decisions if you have any kind of notion of this invariant safety kind of property so [Music] sorry the question is what amounted yeah so the cool thing about that I've been able to do with this protocol is to allow every node to have their own fault tolerance threshold so I can run my nil attend a fault tolerance threshold of like 30% you can run yours our fault tolerance are 50% and like you won't lose consensus safety with anyone with if there's less than some less than 50% of Byzantine faults you won't lose consensus safety with anyone with with a tolerance threshold of 50 or more I won't lose it as a safety with anyone with a threshold of 30 or more if there are less than 30 of em Byzantine faults and so basically in some way the fault tolerance threshold actually is not part of the protocol it's something that the client will like input or that is like not you know it's not a first order citizen in the protocol and so I can tell you like oh it has like a fault tolerance of 1/3 the way no people normally do but you know if you expect validators to be on line most of the time and to perform well in terminamos of fault tolerance for consistent safety [Music] yes actually I think that's so the course is over not to choose a lower why would you ever choose a lower fault tolerance number if the network is producing high fault tolerance and the answer is like actually I think it's better for people to choose the highest halt our December the network will really produce safety on because that makes it more difficult and inconvenient for the network to produce less safety makes degradation and quality more costly to the validators yes [Music] the lower number that you have the more ways there are to be left out with a small number false so actually the lower your fault tolerance threshold the more the more ways you can be left out and if you if you say if you have a high fall tolerance threshold you you can you can basically switch to whichever fork the validator is like like reconciled on after the like say like the attack that caused this low fault tolerance node to spin off and so actually I think the probability that you'll have to like manually intervene to resync with the consensus is going to be much higher if you have a much lower few have a lower fault tolerance threshold because it takes less false to it to cause you to spin off it really is like a lower fault tolerance threshold is straight up less secure for the for the users on that on that I'm not sure one like using that fault tolerance level basically because they it takes less Byzantine faults to cause consensus failure between them and other nodes so the only way that you can the kind of way that you kind of can get a lot of safety that way is assuming that all the correct nodes see the same finalize block first but that's a sketchy kind of assumption because like I mean exactly what the adversary will be trying to do would be to show this one or inconsistent finalized block you know in order to make notes kind of fall out of consensus so here's an exciting thing that have mentioned yet like you know so that so this kind of consensus safety proof works great for like okay the binary consensus and the blockchain consensus and we have a few other consensus protocols the integer consensus or have a consensus on a list and consensus on a concurrent schedule and all those are implemented and they have those like prototype and not correct by construction casper repo on the theorem repo and now we're working on sharding also within the same framework where basically because conveniently enough like actually this framework says nothing about the fact that know about which protocol states nodes need to achieve just about the fact that they have protocol states in common in the future they could potentially achieve right and this type of thing where if P is safe here the exclusion of the negation of P being safe somewhere else doesn't actually require that the operating of this protocol state ever find out about whether P or not P in order to enjoy the property of not safe or not P so it turns out that the safety proof doesn't factor against the scaling problem at all and so we get to pretty much exists entirely inside this context for the for the sharding protocol and so basically I have like a very similar I mean basically the sense of safety proof and methodology doesn't change at all I'd have like protocol states that have messages from different shards and an estimator that maps on to like blocks for every shard so basically I have like a sharded fork choice rule and like a protocol states that kind of also mirror the charting and it all fits inside the same kind of safety proof which is kind of why than why all these protocols are called like the CBC protocols because they're all derived and all designed you know specified to satisfy the same kind of safety proof and which makes it kind of super convenient when I went generating new protocols or modifying the protocol like for example adding validator rotation to the protocol required no changes to the safety proof which is pretty cool like normally have to write an F extra safety proof to do notation but didn't have to which is awesome yeah so looking for more questions you know also happy to adjourn the whole thing if you guys don't have any more questions yeah so absolutely absolutely we're gonna penalize Byzantine behavior especially if it causes failure but basically the the goal is to penalize all malicious Byzantine behavior and leave accidental bug cause Byzantine behavior minimally penalized it's bit difficult but if people have like a whole bunch of coordinated failures that causes a consensus failure then I feel like oh well it's hard to pass that off as a software as a random software bug I'm happy you coordinated a bunch of software bugs so basically it's a it's the job of the incentive mechanism to like penalize these Byzantine faults and absolutely that's you know tightly related to however nothing it's a state problem is addressed in the security deposit base mistake protocols mmm the question was are we gonna penalize when notes run different versions of multiple versions of the protocol and isn't that like what's necessary for nothing at stake cool anyone else I think we're oh yeah here we go to have a vision of what a final implementation of sharding might look like in the end well yeah so I mean from my point of view the sharded consensus protocol provides concurrent execution schedule and assignments or different parts of the schedule it's different shards such that if you're running a node and you want to sync up on any shard you can synchronize and do that and such that the semantics of the remove like the virtual machine on the blockchain have to do but like basically they can take advantage of the atom is to be provided by the block structure and by the consensus system so basically I have a very kind of clear understanding of the basic properties that sharding the shard a consensus protocol will have how exactly that will relate to the transaction model is a little bit a little bit of a more open question and but I know kind of like what the consensus protocol is going to provide to the transaction model as an interface but yeah so it's it's it's a good question and I think so gonna be time to find out exactly how the like smart contract ecosystem moves to a concurrent environment okay so the question is a what a call from one contract to another be possible in one transaction and so in Mayan current like sure I'd expect the answer is like yes but the return value doesn't come back within the same block and so yes okay well thanks thanks a lot for coming everyone [Applause]