EthCC 2: Vlad Zamfir

gotcha congratulations remember guys the camera guy hey guys sorry about the weight you know standard kind of thing that happens when you leave your slice to the last minute but uh we made it and uh we're in for a two-hour talk it's a theory talk I'm going to be talking about blockchain scaling um kind of wish I was talking about governance after is talk all that super relevant stuff about vision and what we're doing um but I'm talking about governance tomorrow also two hours come check it out so um let's get started on the tech stuff though here we go um so we have a pretty long outline we have a little primer um for people who saw my my talk in Stanford the first little bit is going to be very similar I'm going to talk about consensus protocols in sharding and I'm going to talk about the consensus Protocols are starting in theory but then instead of just showing you a couple of gifs and saying goodbye I'm going to go through and like straight depth specifications of and give an example of these protocols so that you can kind of believe me that it's a that that it exists and um you know at least in theory um and then so so so so and that's going to involve looking at the consensus values and then at the consensus client and then finally at the four Choice rule uh that this client kind of uses to make decisions and that kind of organizes the protocol so overview of consensus and sharding talk about charting in theory and then I'm going to go into talking about the sharded consensus values for an example protocol and then we talk about the client for the consensus protocol and then I'm going to talk about the fork Choice rule uh and then we'll you know have some closing closing stuff so it's gonna be a little ride there's gonna be some tough Parts I hope you bear with me um I'm gonna try to take it slow so consensus Protocols are all about making decisions in a distributed Network in a way that's kind of consistent where the decisions are in some way not contradictory across the network and normally we want these decisions to be happening eventually so we want them to be consistent in having eventually normally we talk about that as like safety and liveness and there's some other things that we want but let's not worry about that too much the reason why this is hard is because in a distributed system really you know nodes have different views of the network they don't all see the same thing and so they so it's really kind of challenging to get notes to do things in a consistent way when they see rather different things and also because there might be faults in the network but you know consensus protocols like decide usually on values or on predicates or values so when you decide on a consensus value you know it might you're gonna decide with finality on a value when you decide on a predicate it's just like a property of a value like for example this block is in the blockchain you know then that basically is like you know you're not deciding on a blockchain forever the blockchain keeps on growing so you can't ever really decide on a blockchain you have to decide on like properties of blockchains like decide on a tail of a blockchain decide that you'll only ever choose a blockchain that has this tail um and somehow usually you understand decisions to be like output by the node or committed by the node and so decisions and this is some of the hard stuff sorry guys the decisions on the consensus values are consistent if they're the same and not if they're not and they're consistent in the um and properties of the consensus values are consistent if there is a value that satisfies all of them jointly and they're not otherwise so if I have a bunch of proper so like my example here is that like um you know the decision on one one zero is consistent only with a decision on one one zero if we're deciding on values of three length binary strings but if we're deciding on a predicate like for example this string starts with one or the string starts with zero those are consistents because there exists a string one one zero and another one one zero zero that start with one and with zero so you know if there is a string that satisfies all the predicates then they're consistent and these Notions are kind of going to be important for us in sharding as we'll see soon because we're not gonna be able to decide on the whole value right so kind of another thing that I really need to tell you um by going into all this is that consensus protocols make decisions on a predefined domain of consensus values there's like something that they're deciding about a lot of times people imagine that it's like the order of events a distributed system um sometimes it's a bit and you know we can be really flexible actually as to what exactly our consensus Protocols are deciding on but there's a predefined domain of values that they're deciding on great so that was like the primer for consensus protocols you know we're making decisions in a distributed Network there might be fault to making decisions on some kind of values or a little indirectly by talking about properties of those values more like predicates of those values so um and we want to do this in a consistent way because that's what sets Protocols are about right you and I should agree on who has what balances for us to be able to use the thing as a currency for example or any interesting application of cassette supercals you know really needs to make consistent decisions in a non-trivial way so what is sharding sharding is about splitting things up in different parts right charting is about scaling by moving the network and splitting the network up so that it does different pieces of work with different nodes instead of everyone doing the same work so we split up the work we can do more work if we all do the same work you know it's not that much getting done so you know it kind of has this term came from maybe Ultima Online or this computer Corporation of America paper from 1988 or later ultimate online but it's kind of come uh in like the database and stuff world like to be you know used enough that I feel comfortable calling it charting basically sharding fundamentally kind of really means like okay there's more than one bit you know it's more than one bit so therefore a bid is not charted there's no way for us to make a consensus protocol that's sharded if it's just deciding on a bit and so this will help us really understand in a theoretical kind of way what is charting all about right because it's not a binary consensus protocol there is no such thing as a sharded binary consensus protocol because all it does is decide on a bit there's only two decisions it could make and there's no sense in which it's more than one bit just kind of the definition of sharding so binary access Protocols are not sharded and that kind of leads us to a nice little introduction to charted consensus protocols in theory because we know there can't be a binary Charter because that's vertical so we have we know where to start we're going to need sharded consensus values all right we need to have some notion of consensus value that isn't just Singleton but that somehow has different different components um and the decisions in these in these decisions normally in protocols remember on like the values or the predicates but because we're in a sharded context um we're gonna basically assume that we're talking about predicates that describe some but not all of the shards right so like we're going to be interested in making decisions on some shards and not others and so we describe some of the consensus value namely the the bits over here or the bits over there and this is a way to give you know a description of consensus value without saying exactly the whole because that's the value because you might not be aware of what's going on in the search um so decisions are consistent just like in the normal definition if there is this sharded value that satisfies both of the predicates and so if nodes make decisions across the network and they're you know they're different decisions on different predicates we can still ask this very meaningful and important question of whether they're consistent um and so like we're going to be having clients sharding clients that are going to be trying to make decisions on predicates of these consensus values that describe the particular shards um because you know they the the consensus value is supposed to be too big because it started and you know scalable it's big um for them to just to look at all of it so the only concern about some of it so sharding clients kind of have to be understood as like clients I'm hoping to piggyback off of some of your previously hopefully existing knowledge on like clients there's two kinds of like clients there's blight clients that only look at some of the consensus value and there's like clients that only look at some of the consensus protocol messages and these are very interesting different orthogonal directions in the way that you can make a client light in a consensus protocol um consensus value like clients are pretty much always about using some kind of commitment to some proof system so that you can have a small value that a client can use to prove facts that it's interested about the value without having to learn so much more about it we see this all the time we see this kind of today uh in the blockchain header use as a light client the blockchain header provides these Merkel proofs the Merkel roots that you use to check proofs and those are really used by clients to test their predicates of consensus values which are going to be something like my transaction is in this block you know it has this log you know whatever whatever it might be so um you know there's also sharding Solutions where you know they put root they put like Merkle roots of changes that happen to the different shards in the same chain and that is like kind of like this it's kind of you know putting me using consensus values of as cryptographic accumulators to make kind of small consensus values that you can ask small questions about and therefore be light right because you only just look at the whole thing you ask targeted questions about little bits of it using you know cryptography this is very much what we're used to there's another kind of like client called a protocol message like client um which is a client that doesn't look at all the messages you know it says like oh I don't need to look at those boxes I'm going to look at these ones because it knows somehow that like only those blocks are relevant to its decision um so it only you know strategic about what messages it receives as opposed to just strategic about how it asks questions about because that's the values so you know in some way the altcoin scene is a big sharded consensus protocol where people are protocol message like clients only asking for messages from their particular chart and charting Solutions with different validators sets for different shards also are kind of like this because you know assuming you don't need to look at to hear from all the shards you will only look at some of the validators some of the messages from some of the validators and thereby achieve some kind of like client friendliness or light client-ness by not looking at all the messages right because being like client just means like not doing as much work right especially not doing as much work as the whole system right because that's not scalable so that was the kind of introductory part of the talk let me summarize oh my God is this water for me I think I think it is yeah so um the kind of T the the summary so far is that like for to have a short expenses protocol you need to have consensus values that are sharded we need to have more than like a bit to have a starting sensor protocol that's scalable you have clients that are light and that don't do all the work right they somehow need to like not look at all the consensus value or not look at all the messages because that's what it means to do less work um you know just having less data processing less messages so now um we're going to get into some the more concrete kind of part of the talk in some way where I'm going to start to talk about some sharded consensus values that are going to um you know give uh like multi-threaded execution of the ethereum virtual machine with communication between the threads um to give you a night a more concrete idea of how this might translate into such a like you know a high level theory about charting into something that's practical and more real so we're gonna have a blockchain for every Shard and they're gonna have we're gonna have like messages being sent back and forth between these shards and we're gonna have like the an evm execution trace for every Shard that's a function of processing the transactions but also the cross Shard messages when they're destined for the for the for the virtual machine so I'm going to go through this in rather a lot of detail so I um you know I hope you're excited so block has a short ID um out of some set of Shard names for now let's assume so this is like an example protocol you know it's like so that like we can see that this is real at the end of the day there's no guarantee that this is going to be a static set or whatever but for now we're making a lot of simplifying assumptions so we have a a block has to have a chart ID it's like a new thing we don't usually have today already um this is something we're a little more used to uh block has a previous block or maybe it does intend it's the Genesis walk or in this case it's going to be a Genesis block because there's a different Genesis block for every shard a block has a transaction list and an evm post date we're also kind of very used to this or is the Genesis Block in which case it has some Genesis evm State and no transaction list a block has a source block for every neighbor shard so basically my kind of thing I didn't mention here is that like a shard has Neighbors but but for every neighbor um it has a source block which is kind of like where we're going to be drawing messages from uh it's like the like this block might see a block from another chart and it might be you know pulling some messages back um you know as part of the communication model um and so we call them Source blocks and a block has a list of sent messages to every neighbor and it has a list of received messages for every neighbor uh and now we're gonna talk about messages so that's basically like the block structure so block has a free block it has a Shard ID it has a short ID has neighbors a block has a source block for every neighbor it has a sent and received message log or list for every neighbor um and now messages messages have payloads which we might think of as like the call data gas limit ether the normal ethereum call they have a time to live which is kind of like the number of blocks by which it has to be included um or else it's expired and it has a thing called a base sometimes we call a Target which is the block from which that time to live is calculated so like you know the time to live has to start some from somewhere and it starts from this block and when we make a block this is actually going to be the same as the source block but there's a reason you're not put in the message um but we'll skip over that for a second so kind of summary again the block has a Shard ID a previous block a transaction list an evm State sources Source blocks first neighbors and sent and receive messages for its neighbors and messages have payloads time to lives and these like kind of Base block which we use a you know measure this time to live so um and we have a bunch of other constraints so that wasn't it those can't all just be independent to anything um we have some constraints that kind of make it look for many blocks point of view that things are kind of okay and normal from the point of view of cross-shard communication and Crossroad synchronization so let me tell you what I mean so here is like a an example imagine if we have two sources on two blocks that are you know one after the other they're in the same chain they don't have anyone after the other they're just in the same chain and these these these sources have to also be in the same chain so if you so this kind of situation here represents an invalid block because your sources are always supposed to be consistent right in the same chain so in this case these two these two sources F2 and A3 are different chains and therefore this block B3 is invalid just like wasn't allowed to do that because his head it has ability condition as a as a function of the previous blocks in his chain uh if you receive a message by uh if you receive a message after the time after expiry that's also invalid this should be colored red uh so like this message here is received more than time to live after the base for that message and therefore it's it's invalid whereas like here we received the message before and it's fine so from the point of view of every block all the messages need to be received by the time to live um we have this other source source consistency condition which says basically look I'm not allowed to point use a source at a block that has a source that disagrees with my with this block you know like if I point like this this block before is invalid because it from a point of view of its history I mean it doesn't have a nice consistent story here because imagine a three is receiving messages from C1 and now it's trying to send it's trying to suppose for example send messages to this chain but this chain disagrees with it so this block is invalid it's a little more subtle but there's things have to kind of look nicely from the point of view every block so you can't make a block that like makes some weird um in inconsistent communication happen so um we have those these kind of constraints right the messages arrive before expiry that the sources are all consistent so that it looks like from the point of view of any block that there's been this nice concurrent execution of the virtual machine where like the messages have been delivered and um you know from a chain to another chain not from like random other Forks of that chain to that chain so blocks on the same chart are called inconsistent when they're not in the same blockchain and this is kind of what we're used to today we're like two blocks are inconsistent I mean maybe we're used to I don't know if they're not in the same chain uh blocks on different shards are inconsistent if they disagree about um the sources or failed to receive messages by the time to live so if there's this kind of source inconsistency or the there isn't the synchronization where messages are received before the time to live those two blocks are inconsistent so if I choose a block on one Shard and I block on another there can be inconsistent um because of the way their sources and their messages correspond to each other's block structures so a decision on a block basically represents kind of like we were talking about in the theory of a decision on a predicate of the consensus value that says that this block um is in is in some chain and the consensus values here are specifically we talked a lot about blocks but the consensus values are really these executions of all the shards right it's not just like a single block because its value is the mult is like a state of the block a blockchain for every Shard not just any blockchain for every chart they have to be consistent use like according to these definitions so we're instructing the consensus values to look like executions of the evm with multiple threads that communicate nicely and if they don't look like that it's like not a consensus value and therefore if you make decisions that don't look like that they're inconsistent decisions because there is no because that's the value that satisfies them jointly so we're defining the consensus values as these collections of consistent blockchains and so decision on a block basically means that this block will be part of the multi-threaded execution of the virtual machine great so that was like another kind of doozy section um so basically we talked about block structure the message structure and what it means to decide on a block of what the consensus values are and what it means for decisions to be consistent on blocks what it means for them to be inconsistent so remember blocks the previous block pointers and also pointers to blocks and other shards and they have message cues to other shards and they're inconsistent with each other if they don't point to each other in a way that looks like they each have an individual history that they're watching and if they don't receive messages from each other by the time to live by expiring um so and we decide on blocks meaning that like we decide that this block is part of the concurrent execution schedule and so if you're deciding on some blockage chart I and I'm just deciding some blocking chart J they might be consistent or not so the protocol somehow is supposed to guarantee that these decisions are consistent but so far all I've talked about is the domain of consensus values that we're trying to decide on so you don't know anything about that presumably yet all we know about is like okay we're not deciding on a bit we're deciding on this kind of complicated block structure that like we can use to represent communicating threads of the ethereum virtual machine great I'm glad everyone is 100 following everything you have a question sure oh here we go microphone side um you had like Char uh chardey um showing that like the the message charde sent a message to you chard B um and the block yeah and the block was invalid maybe not this one maybe it was the other one yeah um uh this one yeah it was this one um so so does this mean that a can essentially DDOS B um by by attesting to essentially like yeah I mean in the end at the end of the day yes although you can't tell from this point of the picture um like you should like somehow that depends on the four Choice rule right and like if they were completely independent and we didn't care about the consistency of these communications you could just have a perspective on chart a that looks like everything is fine and perspective on chart B that looks like everything's fine even though they conflict mutually so like it could so the block validity though condition can be detected locally so like this block on Shard B3 is just invalid on chart B3 sorry beat this block B3 on chart B is invalid on block uh invalid on Sharp B just locally right so so the fact that shards can kind of have like correlated decisions um doesn't actually strictly speaking come out of the block validity rules that has to do more with um this relationship between choices of valid blocks between shards right so there's the valid blocks just because you have bad blocks everywhere doesn't mean that your decisions between shards are going to be consistent and the dossing of shards by one another isn't really going to come out of the validity constraints it's going to come out of the fork Choice rule trying to maintain consistency between the decisions on different shards good question um yeah I mean I don't know what time it is but um I think I think we could do another question if anyone has one okay yeah wait wait a second wait a second wait a second noise uh you said you said that each Shard has neighbors and keeps a list of neighbors how long is that listen how does The Shard find the neighbor um well it's part of the protocol and it's not defined so they find it out by looking at the protocol specification and they and the protocol specification isn't fully defined so I can't tell you how long that list is um I can tell you that one Shard has no oh never mind no I can't tell you much about that sorry um no I guess I can tell you that at least one Shard only has one neighbor um but not from anything I've told you so far here from something that like I'm going to mention later um so but and actually like in at the end of the day we're gonna be talking about some like fancy stuff where the shards move around and change their neighbors and then it'll become less part of the protocol but more part of the consensus values um and that will make things less confusing like the reason why the neighbors aren't in the block is because they're part of the protocol and so I don't need to put them in the block because they never change um you know so um yeah a good good question so now we're going to talk about the client right the client that's going to be making decisions on blocks in this charted domain of consensus values um there's two kinds of like clients remember there's consensus value light client and there's protocol messages like clients so we're going to Define these clients we're gonna um for this protocol to kind of get to the point where hopefully eventually I can convince you that this is going to be a scalable thing so we're going to redefine our consensus values using hashes instead of nesting something I snuck in earlier is that actually I wasn't even using hashes I was just I was just saying that a block like has the whole other Block in there um just because it's like semantically nice um and now in our new like client friendly block header of consensus values we have short ID still because those like let's say are smaller than the hash that you might as well and we have previous block hash instead of like a previous block right we have a miracle root of the transactions instead of the transactions we'll have like a miracle root of the evm tree instead of the evm state itself we're going to have hashes of source blocks instead of the actual blocks we're going to have Merkle roots of these scented received lists um although I'm actually um you know a little bit lying about that maybe we want to see the messages for the four Choice rule um but in any case we're not going to see the whole we don't see the whole payload and we don't need to see the whole block that's the base we can just look at its hash because like that's going to be enough for the like client for most of its concerns and then when it really needs to know about the contents of something you can like ask in the normal like client-friendly way for Markle proof so this is like relatively non-radical stuff I think I hope even though now we're introducing cryptography which is a little weird um you know I guess we're all comfortable with that here we're going to use hashes these cryptographic hashes instead of instead of the blocks themselves and we're going to kind of assume that you know these are non-invertible functions you know you can't compute the inverse map um so that like we basically haven't really changed the semantics almost knock on wood um but we you know have this much more Lifeline friendly construction because you can do this these cool crypto proof systems so that was relatively easy just replace some things with some hashes it's pretty pretty satisfying um now for the cons for the protocol message like clients it's a little a little harder um but it's very similar very very similar um and what we're going to do is basically modify the CBC Casper spec that like you know I shared in that draft like release like Devcon shortly after to express like clients um and and this is going to be basically the um you know I'm gonna like describe a little bit now the CBC Casper protocol uh for like clients um so basically normally the minimal paper which is designed to share like the smallest understandable thing that you can check the proof out um it describes a full node protocol where basically if you have a message and it's in your state any messages that are in its uh justification which basically is like the place where it points to other messages also have to be in your state so you have to like have if you have if a message depends on another one you have to have both so you have to have like closure under this notion of justification um whereas in the like client spec we're going to need to give nodes the ability to selectively download these messages we can't like force them to download every dependency of every message right like if imagine if like you know the results will be that they would have to download messages from all the shards which is like the opposite of what we're looking for in this context um so they're gonna you need to be able to selectively download messages from the justification of protocol messages which is a change from the current spec another big change you know in the old one you have we have like just the minimal spec it's like a nesting of messages instead of using hashes and so you know these messages blow up really big and they you know include all the other ones so even if we got got you know optionally had got to include their justifications in our state in some way we'd still be including them because of the nesting and so we have to get rid of the nesting and also replace the nesting with hashes um just as we kind of just did for our blockchain thing in this Nifty kind of trick so but like the kind of gimmick is that we have to maintain and use the same consensus safety proof um because like this the CBC Casper family of protocol like all satisfy this proof and the proof is like really simple and elegant and is like the thing that makes it so easy to do all this work really and so um we have to still satisfy the same proof but like now that we've changed the specification a bit we have to kind of rejigger it a little bit right because um the protocol underneath is like a little bit different and then this proof if you remember if you've looked at it or if you've watched me presented about it before and kind of show that nodes have a common feature protocol state if there's not more than T Byzantine faults you know equivocation by weight vaults and exhibited in their protocol state sorry in the union of their states so we have kind of this setup where protocol states are sets of messages and where you can detect this kind of fault in the set of messages and if in the union of our protocol states which is just like a bigger set of messages we detect more than T faults then we might not have a common feature state but if we detect less than T faults or not more than T faults then we'll have a common future protocol State and this is kind of like a Cornerstone theorem that the consensus safety rests on is this idea that if there's not too many faults then we can all transition to the same state where we're going to be consistent kind of almost trivially so as long as we can maintain the existence of a common future State we're going to have safety and there's a really simple mechanism that we used to do that um oh yeah I mentioned this should have the slide up but you know the protocol states are sets of messages and and the state transition thing is receiving messages or growing sets of messages is kind of the abstraction for for the protocol States um I have a question up there um um thank you so much and so from a set of messages we can we can kind of see some things sometimes hey thank you um so if I download selectively these messages to validate a specific State um isn't that also a privacy concern because I basically will share some sort of information about the state that I'm interested in yes yeah that seems like it might be a privacy concern okay yeah we'll solve that but yeah yeah um I'm sure people will get concerned about that yeah I skipped a few slides did I oh wow oh geez don't look there um so so protocol states are sets of messages and we receive messages and we transition to new protocol states that have more messages it's a pretty natural kind of setup um and in the CBC Casper respect they've got a minimal one with the nesting and just like the simple to specify then prove and like reason about one um like somewhat easier two distinct messages from the same ballot data or an equivocation if neither of them include them in the justification so if like message one isn't in messages two justification or message two isn't in message one's justification then it's called an equivocation it looks like they haven't been just honestly including all the messages they previously made in their next one and they're going to make a little fork and that was somehow bad like this is like what we call an equivocation fault um and this is the way that we normally look at it so do we have two messages the messages have three parts and this is the this is from the this is the Fault counter in the minimal CBC Casper spec um you have two messages one of them has this consensus value and that justification semesters have three parts a consensus value uh validator and just and uh justification because this is value validator justification and these two messages are on equivocation if they're not the same message but the first one isn't in the justification of the second and the second is in the justification of the first so this is like this behavior that I was talking about so this function f what it does is it calculates the total weight of the nodes who have been caught equivocating this is like the fault weight counter and this is a super important part of the um protocol specification because the protocol specification basically says look we're set any set of messages that has not more than t total fault weight so you need to like have the weight counter and prevent your protocol from evolving to a state that has more than two faults um so it's a really core part of the protocol definition is the weight counter and we're now we have to kind of change the definition because we don't have we can just do set inclusion in the justification anymore because we don't have like a set of messages there um and the messages are gonna be somewhat different instead of having a set of messages here we're going to have a set of hashes and usually before we had this notion of validity that the consensus value had to be in the estimator there's like four Choice rule like thing of the justification now we like do the same thing on the inverse of the hashes but the kind of interesting uh so so this was this is the message this is like the message construction I didn't have a similar one for this one but um there's a validity condition that relates the consensus value to the justification so that the consensus value isn't just arbitrarily chosen it has to be justified according to this Fork Choice rule like thing so over here we have a similar justification but now we have to justify it in terms of these hashes or really the inverse of those hashes and we have a fault counter that looks slightly different the fault counter what it does is it checks if the hashes are in the justifications as opposed to checking if the messages are in the justifications so it's I mean I said it would change but it didn't change much um all that happened is that now we check the hashes before we check for membership because like we're no longer dealing with sets of messages we're dealing with hashes so um now we're we're still we're still able to detect the weight of equivocations from protocol States uh we just have like a slightly different definition of equivocation it's still two validators not sending messages that are into the justification but like instead of the message not being in each other's justification it's like the hash of the message isn't in each other's justification really similar definition we just have to like thread the hashing through there um and um and and now we actually have have achieved some amount of flexibility um because we we don't have we don't have this full node constraint that we had before which stopped us from having a selective set of messages in our protocol State now we can have like any set of message you know borrowing the constraint that they can't exhibit too many faults in our protocol state so we could really have any message in our protocol State and any other uh from two different validators and that's like totally fine because like they can't be equivocating um so there's like a lot more freedom that we have now in this specification to download whatever messages we want whenever we want them the question is you know um so so yeah so that like I've kind of gotten my head ahead of myself but I mentioned like you know we're going to constrain the consensus protocol States to only exhibit not more than defaults so like we have this fault counter defined we're not going to allow the protocol states to transition to states that have more than T faults and so uh just as we do in the same CBC Casper protocol and so now we have this kind of proof obligation of running through the same proof again to make sure that it all works out and then we have the consistency of decisions guaranteed by the safety proof for the for the extensive protocols so we need to show the first Cornerstone theorem that if the union of two of these nodes protocol States doesn't exhibit more than team faults then they have a common feature state and um my like witness is the union itself so the union itself is a future of all these states because the union itself is supposed to not have two more than two faults and is a superset of each of these states and they can all transition to this set by receiving those messages so we have this common feature protocol state which is the union of their protocol States and so that guarantees that they have a common future um you know assuming that the union doesn't have two or more faults so that's pretty good so we have a common feature State um if there's not more than T falls in the union of protocol States according to the exact same argument as before um and you know this there's the converse where like if two nodes don't have a computer protocol stage what that must mean is that there are more than defaults in the union of their views you know two and whatever uh and this is like the you know real the way like nice interpretation of the safety results which is that like if we have a failure then there must have been more than defaults so that's the kind of first Cornerstone part of that because that's a safety theorem that we want to cover the second part twice so I just like pass over it earlier um the second part basically says look we're going to use somehow we're going to use the existence of a common feature to guarantee the consistency of decisions on predicates of cassettes values um and the way that we're going to do that is um through this notion of this estimator or Fork Choice rule that relates protocol states to consensus values um and it's going to basically talk about what are your valid guesses of consensus values from different protocol States and a property of consensus values is called the cited if in all future protocol States all of the values of the estimator satisfy that property so from this set of messages and all supersets that exhibit less than two faults the estimator or slash Fork Choice rule will have this property uh then it's decided so that's the definition of decided that we that we use in the CBC Casper world it's kind of like um invariance in all future protocol States and so the and so we kind of have this guarantee that um they're going to be consistent because they have a common future state and so if something's invariant in the future States and they have a common future state it must be it must hold in their common future State and since it holds in a common future state that needs any of the values the estimator that state will inhabit and satisfy all of those properties which is the definition of consistency so we're golden on the consistency front uh with this definition of decisions so um and we have this common future guaranteed if there's not too many faults so we kind of all in all have consistent decisions if there's not too many faults which is the consensus safety result or really like flip the other way the only way to have inconsistent decisions is if there are more than two faults and that's kind of like the Baseline uh requirement for a consensus protocol to be to be safe um and you know my claim is that like I just ran through the proof sketch and looks exactly the same as the like CBC Casper proof for the full nodes um only there's like this there's like hashes that had to be kind of threaded through everything so um but it's the same proof same principle you know that we have a common feature state which is the union of our states and we have the same notion of decided which are invariance in all of our future States the thing that has changed a little bit now is that the estimator has to be defined over a much broader set of States like before the consensus the four Choice rule was only defined on these full node States now it somehow needs to be defined on more States and we're about to get there um but let me take a sip of water first yeah Martin has a question I'm sure it's going to be good um I'm a little confused uh with how the abstract proof where you talk about messages applies to This Light client setting and specifically I'm wondering um what it seems like we have two Notions of dependencies where where it's the dependencies of messages being included from from neighbor shorts and the blocks that are directly below you are both of those dependencies included in the justification of messages so over here um and this in this in this level of the specification I um I wasn't looking at the consensus value like client at all it was just the protocol messages like client and so I would so the consensus values are just kind of black box to me like I don't even know they're sharded in this like client spec what I do know is that I don't need to look at all of the messages and the justifications of the consensus values so the spec I gave you are specifically the protocol message like clients not the consensus value like client and so the nesting of the blocks underneath like I don't know it depends on the consensus value is it a header chain is it like a you know um you know um so like that kind of depends but the but with respect to the consensus messages the protocol messages you know it says that like you know there's the the messages in the justification are kind of covered by hashes and like you could download them if you want as long as they don't show you too many faults so to actually decide if something is an equivocation you would need to like look at the contents of what generated all of those hashes so there's there's different things that you could decide are equivocations there's messages in your protocol State and there's messages that are not in your protocol state so if you're talking about messages that are not in your protocol State like yeah that's one way to get them is by is by downloading the dependency to the messages that you have and that could reveal equivocations but you can also get new equivocations by downloading messages that aren't in the dependency of the message that you already have okay cool um yeah that's definitely one of the interesting areas um where like you could discover equivocations in your justification um and the interesting thing that happens there actually is that it kind of um forces a kind of triviality of the decision so here's kind of a thought experiment this is kind of going a little deep you guys I'm sorry imagine we have a protocol state that has more than T faults in its extension of all of its dependencies and there's two possible ways at least to extend their dependencies one that shows that side of the equivocation and one that shows this side of the equivocation and they're mutually exclusive and that you if you if one note extended one and one node executed the protocol by resolving the others they would not have a common future State anymore and so so so you could get to from the same state just by resolving the dependencies or downloading the justifications get to two states that don't have a common future state and now suppose that on one of those p is decided and on the other not p is decided then what that means is that neither P or not P could be decided in that initial state and so in the weird cases where this dependency leads to different decisions then it can't have been the case that those decisions were made in the initial State before it was enrolled and so rather than it leading to uh inconsistency it leads to a kind of more triviality in the sense that there's no decision uh in those cases that you would suspect might be inconsistent um definitely interesting defense stuff sorry guys going there um but you know I'm sure if you're finally curious that's great come ask me more later um so um yeah I mean if there's any more questions can anyone tell me how much time I have left um there's a question down here [Music] when the inconsistence actually the dependency is very long for example you have like two forks for one shot a A1 and A2 and A1 depends on B and B depends on c c depends on A2 so here the incense inconsistency is actually very long how to detect this yeah so um that's a good question and like what we end up doing in this example is we're going to arrange the shards in a tree uh and it's going to stop that from happening um but uh in general yeah that's definitely an interesting and challenging issue sorry grab the microphone would you please uh Dynamic rights so it will be more even more complicated yeah and we have done actually uh changing of the shards while still moving from tree shape to tree shape and it and we've been able to sort everything through because like from the point of view of every block it's always like a tree even though in some way overall there's these Cycles um and but definitely this is something that we're kind of you know mindful of and we just don't let the Cycles happen okay yeah but if if you want to change the structure of the tree along with the along with time then you need to kind of have another level of consistency to or consensus to maintain this right among all the shots um yes and no so like the definition of the consistency doesn't change actually because the shards always um are like single threaded and they always have like a consistent like you know kind of view so so somehow um I'm not sure that the definition of consistency changes but definitely the uh Fork Choice Rule and the validity and the questions that you ask are going to be like different you know the shards you're looking at like your neighbors are going to change yeah actually I agree that the Choice Ruiz the the key to Southeast okay great um so if no one else has any questions let's get going all right so now we're gonna talk about the four Choice rule right so the four Choice rule is going to relate our protocol States to the consensus values right somehow I'm going to relate this abstract blight client that I just made up to this these sharded protocols right these sharded blockchains the the different blockchain for every Shard with the messages and the pointers you remember I hope um so we're gonna take possessive values from the sharded blockchain thing and you know our protocol States from the thing from this from the minimal CBC like sorry for the from the light client CBC spec that we just get so for clients to make a decision they need to understand what what messages did he's actually look at right we kind of said that oh look a client can look at whatever messages they want but we haven't actually said which they should look at right so we're gonna it's gonna get a little more concrete here um because we're gonna so we're going to structure the fork Choice rule to help inform them so that they have like a clue about what messages to look at to decide on the blocks on different shards um so we're gonna kind of you know connect the decisions on different blocks to different sets of validators that are responsible for this for the fork choice on different shards um we're gonna assign like different you know assume mutually exclusive just so they don't think about it um subsets of validators to different shards and this way a client knows okay which validator is on which charts let's assume is part of the protocol um and furthermore we're going to separate the neighbors out into two kinds of neighbors parent and child and they're gonna say look you only have one parent at most and one only one shot has no parents I said this forces us into this tree shape of neighbors where the you know children are further down in the tree than the parents so and then we're going to make the four Choice roll of A Shard be independent of the four Choice rule of its children and you know the flip side is that like what we're really trying to say here is that we're going to make it dependent only on the Fortress rule of its parent so if I know the four Choice rule of the parent I could execute the four Choice rule the child but I don't need to know the four Choice rule of the child to execute the four choice of the parent it's kind of this one-way dependency of child on parent um and and this is going to achieve a whole bunch of stuff for us it's going to let validators know what validators they need to hear from in order to make decisions it's gonna show them they don't need to hear from everyone they only need to hear from some subset of the validator set and it's going to allow us to make the decisions on different shards dependent um which is super important because as we kind of remember the decisions on different shards only consistent based on a property of you know the blocks like a relationship between those blocks and so um that we really need the choice of the chard on different choice of four kind different shards to not be independent right it'd be really kind of easy we didn't if we if they were independent but we we need we need we need non-independent choices so that we can have consistency across charts of like you know things like The Ether Supply and all sorts of different kind of cross charred communication guarantees like you know the call I sent is the one that's received and when I receive a message back it was actually sent by the place it was supposed to be sent for almond there's there's all sorts of like cross Shard consistency that we need um and so this property of the children's four choice being dependent on the parents is going to be really operative um and so now I'm gonna give a fork Choice rule that fits all those constraints that I mentioned and um guarantees that our Crosshair communication will fail and that across card synchronization won't fail so the here's the four Choice rule in like English so the first the the first things to note is that the root Shard executes the latest message ghost message driven Ghost Protocol independently of any other charts it kind of just does its own thing on valid blocks like when it looks at its blocks and it'll just run ghosts on them um and then the other shards are going to do almost the same thing but they're gonna orphan blocks that's quote failed to synchronize with the fork choice of its parent so and what does it mean to fail and synchronize well we're gonna basically I call them you call them we're calling them filter conditions like we filter those blocks out before we run ghost basically like you know ghost is no longer allowed to choose those blocks because they somehow fail to synchronize with the parent chart and notice that this filtering is a about a relationship with the Fortress of the parent it's not about uh it's not a local validity condition right so like if it's the kick there's very clean separation between the stuff that's enforced by the fork choice and the stuff that's enforced by the validity conditions so here they are the four kind of conditions so the chart here on the right chart B is the child chart these three blocks here are out of sync with the parent because in the parent Fork choice there's a source to a block that disagrees with them so the the parent is for Choice here ends in A4 it points to B2 these blocks are not consistent with B2 they are orphaned so even though they might have been chosen by ghost in the child's Shard otherwise because it's not synchronizing with the parent for Choice rule they're going to be orphaned so you know throw those blocks out and then run ghost another thing that can happen is the a block could on the child have a source on the parent that got orphaned in the parent so like in this in this diagram here the parrot orphan this block that is the source of this childblock and therefore these two blocks need to be orphaned those two blocks both have sources that are inconsistent with the four choice of the parent and therefore don't synchronize with the parent in this way that we expect if a Block in the child fails to receive a message by the time to live it gets orphaned so imagine if like in the four choice of the parent there's a message sent to the child and there's a block in the child that doesn't receive that message by the time to live it will also get orphaned so these two blocks up here they they failed to receive this message from A2 that had to be received by the time to live here which is two heights and they didn't do it and so they I mean they didn't know maybe about this block ever existing at the time they were made it's totally legit um but eventually the four Choice rule became this and it sent this message and these two aren't aren't really allowed to be in the Fortress role of the child because the child has to receive those messages by the time to live they're in the if they're being sent by the parent like that and similarly if a child sends a message to the parent and the parent doesn't receive it by the time they live that block has to be orphaned right like if you're sending a block sending a message to the parent and parent doesn't accept it or doesn't receive it for whatever reason I mean you're not synchronizing with the parent you got to go um and those are the four validity four filter conditions two of them to do with the childblock disagreeing with the fork choice either with its source or with sources from the fork choice and two of them to do with a child either not receiving a message by the time to live or failing to have a message be received by the parent by the time to live so notice it's always the child orphaning in the blocks in order to maintain synchronization with the parent because we have this constraint that the parents poor choice is independent of the children and this really will help us make sure that you don't have to look at all the shards because you don't need to look at the children of any shard uh to determine the four choice of that chart so here's kind of the claim that these constraints and not are enough that Crossroad Misty failures can't happen um because they will be eventually orphaned because it's one of these rules will say look you know you you you have to be filtered out of the fork choice and therefore you'll be orphaned by the fork Choice which is a function of the parent chart and here is this like demo of exactly this protocol that I just described using exactly these filter conditions and these validity conditions that are described so you can see here what happens is sometimes there's a bunch of blocks that are produced in the child and then orphan those let's see if we can see it happen um if not we'd have to wait for this thing to restart because it happened a little earlier I'm gonna try oh there we go we saw for a second so what I'm trying to see here is the fork Choice let's go to this green line not make it all the way to the end because of the filter conditions that drop blocks so here was gonna be a little you see that walk for a second you look at this one look at this you see these blocks are getting orphaned even though they're at the tip of the chain it's because they don't synchronize with the parent meaning that they don't receive messages in time or um you know by expiry and therefore I need to be orphaned by the child lock and so these and these these these thick purple lines correspond to a sent message being received in the fourth choice of the parent and the child the nice thing about the model is that we get like once in time message delivery in order you know as you kind of might want um and these these little thin ones are a message that was sent or received from a block that's orphaned and so I'm still just drawing them but those are into the Fortress really more so um the claim here is that the CBC Casper client for this blockchain won't make inconsistent cross-start decisions um you know remember that cross charge decisions are inconsistent if you choose blocks that are inconsistent in the sense of this pointer thing and the message delivery thing which exactly are the ways in which we're orphaning blocks if they don't satisfy um basically the clients can determine what validators they have to hear from right if they're interested in a Shard they got to know from that valid they don't know all the values in that Shard all the validators that needs parents all the validators on its parent all the validators are its parent and so on so you know logarithmic number validators in the total assuming that every chart has the same number um and therefore they need to hear only a really small minority of the messages um which is you know kind of unless we have a like we could have had like in this previous example just like not a tree but a single row of shards and that wouldn't do that wouldn't necessarily do it for all the shares because the one at the bottom would need to see all of them but uh if there's a single Shard with more than one child then we like achieve some scalability and these so like I really think you know I'm really I'm convinced that uh polite clients deciding on blocks we're really going to implement a scalable blockchain consensus protocols that like you know we have a blockchain for every chart so um this is kind of the claim I mean I I hope I've Illustrated it enough but I'm ready for questions uh and clarifications just in case um I haven't really tied the knot enough yeah please oh over here you'll mentioned that you arrange all the shots in your tree structure right and if you want to have a cursor transaction between two leaves the inmate needs to go a very long pass right yeah that's right so so so we have kind of you know you kind of need to like Mom we kind of do modify the you know basically this is like the simple example but what we like to do is you know have a routing system so I didn't really mention the routing but yeah we have to Route across the path to get to get it around through the system yeah okay that's probably not sometimes not less efficient well but you have really but it's really strongly guaranteed to be Atomic in the sense that either the whole route will be eventually finalized or completely orphaned um yeah yeah you know assuming that the protocol is live um hi regarding the the time to live requirement for the childblocks is there a possibility of ending up in kind of a bad state where they're they're say there's many many messages with the same TTL so they all have to really go into the last block but those messages such that they can't all be included in the same block because the gas costs and so that that chain is sort of broken where the previous block was fine but there's no way to validate the next block yeah go back two blocks so at the moment um this doesn't involve gas limits or any of that kind of consideration but absolutely it's going to matter um and uh definitely something that we're going to need to think about I mean there's there's like there's there's like these things where you know you have like you could allocate gas but then what about then like you're not really operating a capacity because of the unused allocated gas but it's definitely interesting an interesting problem and something that you know you want to work on anyone else anything any questions yeah okay over there I guess uh not really playing the traveling salesman microphone game oh yeah I I'm wondering do you think it will be possible and if so any direction how to do synchronous cross-shared Communications yeah so um we're totally looking into synchronous crossyard communication and uh basically um you can definitely have like a synchronous communication model you're not going to have like exactly the atomicity that we're used to today but you can have a contract like waits for a return value and be kind of blocked there until it receives the return value and then execute other messages only afterwards the concern and issue with that is basically Deadlocks and so you know if you have like a you know you can have like a deadlock haven't and so you have to kind of clear the deadlock and there's um and then there's definitely we're doing ongoing research in that although I would say that like the like in today's virtual machine like the solution to this deadlock situation is re-entrancy and you know it's presumably preferable to deadlock and so but then if you're doing re-entrancy okay it's not exactly a synchronous call anymore uh uh so somehow like you we don't we already don't have synchronous calls exactly um but it's definitely an interesting area of research that we're kind of digging into because we don't really know the best communication model for smart contracts we just want to provide options and let people test them and see what they like oh there again yeah yeah so actually I will follow up question with my previous one so uh so right now because of the cheese structure or the Crosshair transaction from the left substitute to the right subject I need to cross the route shall rights so do you think it would be a bottleneck yeah so I mean I think the this is the reason why like balancing is super important and like the approach that I have is load balancing so the idea is like okay we're gonna move actually the shards around and the contracts around in order to minimize the overhead of the solution and to maximize the scaling that we get because yeah the routing has overhead uh and things are faster if they're closer together and this I think is one reason why multi-level sharding is a little bit more sophisticated and like just one one level because routing everything through the Hub is you know could be a bottleneck account hi hey Rick how's it going Vlad I'm all right do you have um any thoughts or views on data availability of the what's actually hashed and and how that gets moved from Shard to Shard yeah that's a it's a great question and leads me right into my next section in my talk um of like other relevant work slash future directions in this research or like related closely and after the research um so we talked a little bit about this right now just like the message routing and The Shard rotation validator rotation we haven't really mentioned but we want to change the validators around we're actually gonna make some changes to the consensus values and be a little tricky about how we do that um so like we have definitely some more changes to make to the protocol and one of the things that is kind of relevant to these protocols is actually guaranteeing that these blocks are valid and available so far I was just assuming that look this is actually the hash of a valid message um and that like you know if I need to get a message from a block you know if I need to download blocks from a chart I'll be able to and these are kind of like known to be some of the um you know like I guess potential problem areas with starting Solutions is like assume that like no one knows that something is invalid like no one can tell it's unblock is unavailable uh it could lead to problems going forward because you know clients can't decide clients clients can't join clients decide on things that involved valid things in justification um but the reason why this isn't this isn't part of the solution at this level is because these are not consensus protocol issues right these these are our availability and of validity issues which are in some way a categorically simpler distributed systems problem because they don't involve the consistency of decisions across the network but our local questions that can be verified locally and so you know we can build and have built and are looking at more in the building I mean like at least in theory and we and we're going to build them in practice eventually you know systems that have all of the kind of properties that we want out of the census but here also you know fault tolerance the economic incentivization and the you know normal kind of security stuff that we talk about so the answer actually is basically that like yes it's an issue yes it could really screw things up and but um the computer science actually is relatively easier and the uh you know to provide like fault tolerance economically Secure Solutions although um you know this has taken a lot of attention because you know it's a it's a problem that okay everyone even ever that all the sharding solutions have like every sharding solution has to deal with it somehow um and so it's it's definitely an interesting an interesting one um you know I have thoughts but I actually believe that like having the scalable blockchain architecture really helps solve these problems because you can actually use the smart contracts available on the scalable system to do some of the games that are associated with block validity and availability protocols you know challenge response games games with cryptography um and smart contract so I think that the correct approach really is to solve blockchain scaling first and then to build the data availability and uh validity layer on top of it just like today we expect the blockchain to keep itself available and valid we should like expect shards to keep themselves available in ballot in a distributed way and not just like with like a single centralized um availability and validity solution oh okay so I guess for me the the the one of the last things you said there was really uh sort of got to the essence of of my concern which is that we see the limits of data availability in the existing blockchain Solutions we uh in ethereum 1.0 world we can very quickly imagine a situation where we don't have at least a convenient answer uh uh for data availability I agree that um these are easier problems categorically to solve um but I think that there's still um I think within the community at large there's there's a a sort of ostrich head in the sand around how expensive data availability uh really is and and I think that I saw sort of to prompt your response here um are you worried that in a sharding context um the real sort of you'll you'll have this algorithm that'll be very powerful and correct but the thing that actually limits the system is the availability of of the data um I mean I'm I'm not super worried about it at this level of the protocol spec because like I haven't said how many shards there are you know and I'm pretty confident that we could do two I'm pretty sure we could do four I don't know at what point it starts to be harder but I'm I'm comfortable with the idea that we can um figure out whether the data is available super robustly like how many like and we can think about like you know what is the cost of a node and bandwidth and do the kinds of calculations and actually one of the things that uh makes me most optimistic about solving this in the long run is the idea that with scalability we can have actually realistic peer-to-peer micro payment markets four dollars these files because like if people were paid if it wasn't a public good to provide this but it's actually like if there's like a market for file provision that is like you know efficient and scalable then I think that this solution you know although the public subsidy kind of protocol is still interesting um you know is a lot more manageable because it's not being provided as a public good anymore like it is today right like if you look at like oh my favorite example is like the EOS availability problem where it was like free to make transactions and now they have like I don't know just like wait what like a like of it like you know too much data uh and we have this rent issue in ethereum too and like you know blockchain sharding doesn't get rid of the need for rent um and so I think like this General trend of moving away from um assuming that people will provide things with public goods and paying for them if they can be you know if we can design the mechanisms so that they don't have to be provided by public goods will make us feel like a lot more comfortable about the sustainability of of uh you know the these like essentially public essentially Public Services of of finding blocks some more things that are relevant and um a little bit um that I have discussed yet is this idea that like you know of like protocol Behavior strategies and liveness so far all I've really discussed here are is like the message structure ranges like data types like this struck the like data type of the protocol State and like the data type of the messages I haven't talked about like when node should make messages when nodes should receive messages and like what their strategy is very much at all um and that's something that is you know ongoing research and um I'll mention a little bit more later maybe about it but please question a question uh yeah probably I'm a bit ahead so I want to ask about the incentive design so right now because of the chase Junction against the the shots they are not equally they have don't have an equal role in the I mean economically right yeah do you have some like plans for this yeah so the there's so basically the um there's like a few responses like one of them is validator rotation right validators move around you don't get to decide that like your validator is going to camp in the root chart and like you don't you know you're never leaving so validators like we'll have to move another thing is that the shards rotate also so we can you know and also the smart contracts move around and so like at the end of the day when we like are really talking about like the kind of the Target that I like you know I'm envisioning that actually will be usable in the like like really usable um yeah and the rotation really the uh it's getting too complicated so it's really hard to design it yeah you would think so and I mean like that's one of the really cool things about this whole approach I think is that like the extent to which I can come up with really complicated consensus protocols in a really disciplined way of choosing the consensus values separately first and then choosing the four Choice Rule and understanding that my decisions will be consistent because of the framework and not and not having to worry about the distributed system stuff almost at all because of the because of the definitions and framework that we have yeah so I think that like you know that's like owed to the theoretical foundations um you know no I'm not really thinking actually we are also like designing a shutting protocol it's different shade-offs so maybe we can discuss afterwards okay sure yeah thank you for the great talk yeah no no worries my pleasure um and also so yeah incentive design all the proof of stake stuff right bonding unbonding like fees uh penalties the we also like are going to have and want engineering and like efficiency improvements in our algorithms um and we're going to eventually want to do like performance profiling and like you know of actual let's get some idea of like you know how scalable might it be using like for example like today's ethereum transactions or something that generates transactions it like tries to give us an idea so here's this like GIF of the pretty cool like we'll visit him with a routing and Shard rotation um this one is this one's a cool one this is my one of my personal favorites uh this is like showing the rotation of the root Shard um and like you know there's still like the notion of parent and child in this system is defined on a per block basis and the purple blocks are parent blocks and the beige blocks of Chad blocks uh and that provides like a much more a much less hierarchical structure um and like provides less less of a centrality to the root Shard which I think is like you know um I mean it feels really good to have that um so basically what I've tried to kind of so there's like I guess like a few takeaways right um you know the we really need to think about like the consensus values that we're deciding on with the scalable because as protocol as like consensus values when you think about our like clients or sorry about our consensus clients as like clients that aren't looking at the whole value and aren't looking at all the messages um you know these protocols exist um and you know it's a supernatural way to scale consensus I think and I hope that you've noticed that like all almost all the decisions that we've made have been very minimal natural kind of choices um not trying to do too much they're used to anything too heavy duty um and so like you know I would say like sharding is actually like a relatively simple thing in theory right now to me you know in this consensus protocol world like we can really like Shard them by sharding the consensus values and having like clients um and we have like the same consensus safety proof like it doesn't change at all it really ends up just being a simple natural way to scale consensus protocols so you know sharding is like relatively here in theory another thing I want to say uh is that you guys should attend the CBC Casper workshop at 4 45 today um Aditya who is maybe in the back there uh you know I was going to be hosting this seminar he's going to talk about CBC Casper uh for yeah definitely be there and I was gonna do q a at the end um but I'll totally take some you know some clapping right now if you guys don't mind [Music] thank you thank you thank you thank you so my question is uh what is the minimum amount of information in addition to the protocol definition that a client needs to trust in order to join the consensus um well in this protocol definition the validator set is like totally in there and so I mean it's totally fine I mean you can just join right in validator set is there forever you know it's like permanent um but you know like a more practical solution you know you would have changing validator sets and it'd be like just the same as the proof of stake world where you need to know you know enough validators to authenticate the changes to the valid data set going forward um you know I wonder if we can get some scalability gains on that uh it's interesting but like in my mind it's basically the same as as like proof of stake uh sorry I won't wait for the mic is it only the shards validator set or also the some validators from from other shards or um or the root or something I mean it's it's I don't know exactly what you're asking about like are you which so it depends on what validators you're trying to learn about right so if you're trying to decide about the this Shard like you don't need to know about all the validators over there but you do need to know about like you know this validators that were maybe on the parents Shard and it's parent and it's parent so like you know you don't need to know about everyone but like you know you do need to know someone who's currently bonded in order to start to authenticate anything in a safe way um and they I'm not sure if you need to know you know I don't think you I don't think you'll need to know everyone uh but you know it's an interesting question I I'll admit that like I usually just assume that it's the same as for mistake and I haven't given much thought into making the uh weak subjectivity thing a little more scalable um but uh you know in the worst case you just need to know all the validators on the brakes that you're concerned about okay thank you cheers yeah maybe stop here first so you don't have to run back and forth all the time yeah hopefully we have time sorry for so many questions uh yeah I found this very helpful to ask you that really big other than I have to check on the website uh check on the Wikipedia it's not very clear there so my question is not technical this one uh it is the version that Israel would use in the Eastern 2.0 or is this your version of well I mean I hope so but um it's definitely not the official roadmap okay I see okay that's all thanks yeah my pleasure yes what are the uh what are the properties that your protocol is trying to optimize for um scalability and um I mean so I have like it's all kind of in line with the non-scalable research also so I want to have like extra protocol for tolerance thresholds I want to have like no rounds I want to have the possibility of having theoretically optimal Network overhead um there's all sorts of like like design criteria um you know having final decisions instead of like not um being able to um you know have a latency below and explore this trade-off between like latency and overhead there's there's I have a I have a whole list of design requirements that for normal consensus and they are all carry over here and the only additional one here is scaling really all right so Rd is ridden down somewhere or um probably but it's probably not too easy to find okay I'm sorry we'll we'll get better um I do have a question uh about do you have any idea of what the size of the message that would be crushed Charles uh What proportion of message like if you do I don't know empirical studies or things like that no I have no idea um but but I can tell you that they're not going to be too big there's not going to be too many of them yeah sorry I mean you know I'm a theorist so uh what are your thoughts on on complexity obviously in uh this is kind of growing into a bit of a beast it's a beautiful beast but uh obviously there's some sort of trade-off between Simplicity and complexity what are your thoughts on that and and how how do we keep it under control well I mean the way that I kind of do it is I think about like what are the design requirements and then I like try to come up with the simplest thing that could fit them all and I don't try to keep up with my design requirements unless I like can prove that it's impossible to meet them um and so I I kind of start from the requirements and then and like you know and like I swear it's only as complex as it needs to be you know um at least like but but but definitely you know um this is something that like people argue about like what are really the requirements right like no one agrees with me on my list of design requirements uh uh but you know I assist I insist um you know I mean maybe not on but but basically you know I don't I'm not trying to do anything too complicated really I think uh I think it's actually all rather simple uh really yeah hello hi uh here I don't see you oh there you are okay when they think uh shorting will be released on the mainnet um I don't know you should ask vitalik yeah I don't know I don't know that's a good question um it's always a good question we always get it okay thanks my other favorite answer is soon another one is as soon as possible two weeks two books two books yeah that's a classic all right well if we're done if we're done with questions I'm done with my slides so you know thanks so much everyone really appreciate it