9. Discussion: Casper loves sharding and everything

we combine everything all together on this day that the ending of this day so this is the open panel for everything you can we can discuss during photoshopping research implementation the roadmap the plan the happy thing the SAPS team so let me start from this so this retails we discuss some phase 1 and phase 2 plus and we dig in digging to some Spacek important topics like the POS start the proof of chastity and he wasn't p2p and viber and everything and so first question is what do the researchers think of what we can do immediately well first of all you can build a plasma chain because that doesn't require waiting for anything thank goodness Blatt is not here I'm sorry well so kV I hope we didn't hurt your priors too much inside jokes inside choic spacian so I mean one thing definitely peer-to-peer network that is something that definitely stood out to me the fact that she'll way I remember multiple months ago talking with Xiao Wei trying to figure out this pub/sub thing and saying you know just use lib p2p and then realizing that that's just not going to scale up and so hearing that it's still definitely an issue it seems like that's you know right away we need to solve a peer-to-peer network that that you know can work for scalable peer-to-peer applications because we not only as sharding one of one peer-to-peer application but they're going to be a huge number that hopefully can reuse some of the work that we do so that's at least one we're not certain whether it work or not so we should probably do some like load testing I know some of the teams are interested in like writing code in reference to the beacon chain and I think that you should to get more familiar with the spec and to kind of open the dialogue about some of the maybe edge cases and things that we all need to think through from an implementation side so if you want to write some code write some code I think though we were talking about opening a getter channel that's a kind of beacon chain getter channel where we can discuss the beacon chain SPECT specifically and to discuss some of these proof-of-concept implementations further as we've been already this weekend I just want to mention that so it's an open discussion so if anyone has some strolled please don't wash your hands one interesting question I've heard a few different sources is the and I think that I have a clear understanding of this but adjusting it really fills in a little bit more the the vdf to some people the video sounds like okay we're just burning how cycles again how is this not that house is not us just burning hash like looks like a plantation so one thing I guess to mention that maybe wasn't clear is that the vdf idea is actually quite recent and we haven't figured out all the details in terms of why vdf isn't like a race to zero where everyone burns a lot of adversity I guess the reason is one it's proof of sequential work as opposed to proof of parallel work and to the game is is prone to to being a monopoly so basically whoever's fastest at providing these vdf outputs and proofs can basically be the timekeeper be this this is participant in a network that provides a heartbeat so in terms of attacks that that can happen there's this two ones which which Vitalik found number one is kind of the more obvious one so if so the main problem is basically an attacker with customized hardware which can compute the video faster than everyone else so there's two bad things they can do number one is kind of not reveal publicly reveal the vdf outputs but still know them before everyone else and basically be able to grind the the entropy pool which is based on R and L in order to get a favorable random number at the other end and I guess the second attack is in order to keep the five-second heart beat we need a difficulty adjustment and so the worry is that if there is an attacker who's let's say 10 times faster than the rest of the network they will push up the difficulty quite high and if they suddenly go offline then we don't want the whole system to stall and it turns out that so long as we can get the advantage to be reasonably small let's say on the order of 10 or 20 meaning that yeah the attacker is no faster than 20 times the rest of the network and we should be ok but you know I guess there's some research work that needs to be done in terms of what is like the theoretical optimum you can you can get with state-of-the-art Asics what can we do with GPUs and CPUs what can we do with FPGAs what can we do with like a very basic ASIC which wouldn't cost that much money and make an informed decision based on that so to answer again the question of like why it would not just go back to a proof-of-work race for more clearly like basically because it's proof of sequential work your ability to do more work by burning more money is very sharply limited right so yeah it's money billions our attacker may be able to complete the work something like 5 times more than okay or then someone with a few hundred thousand dollars so we're as opposed you know at 50 thousand times more basically because there's only so much that you can optimize a single-threaded computation and now one question that I think we should obviously look at is like if in case in the case that the system does settle into some kind of monopoly equilibrium then basically no one else would be getting rewards and so there would be no incentive for anyone else to I compete with the attacker and make sure that they're and kind of help keep the advantaged small so and there are tricks that you can do it surah try to and have in the rewards to be more distributed so one example is that you can kind of combine the PDF mechanism website with hash reveal so you can for example encourage like specific like different specific validators to lay down a hash and that or a pre-image and then lay down the preimage of the hash as well as the vidi the the vdf results sometime later and that would basically give that particular stager a kind of monopoly right to the ability to make that particular vdf solution and then you could assign them some kind of reward so there are still sort of economic optimizations to be worked out to make the design maximally safe it's my understanding correct that the motivation for adding this vdf gadget is because of issues with just a simple random simple ran'tao basically has the problem that any particular participants can exert one bit of influence on the ran'tao by basically not showing up and this can affect kind of short-term randomness so we can affect the end of the or the sequencing of queries going to be a proposer and so forth now there are ways to mitigate the effect of that the what the order so in the existing a really really expect the order of reveals is based code you reveal every time you make a blog make a blog proposal if it if you try to manipulate Rand out by not showing up then don't you get punished because you do but the caught but the cost of one bit of manipulation is only one block reward or obviously it can't go much higher than one block reward wasn't the old random scheme then it used to be maybe yes but no so the old rendao scheme is allowed to have much higher penalties because it had really long periods for submitting the random value but here the period is like basically one block line now look there are things potentially that we could do to sort of improve the economic parameters so for example having a penalty for not showing up that's how the largest say 1/8 could be uh could be an okay thing especially if we create a lottery where if you do get incorrectly then you get a reward of one even so it's but like even still the level of many people ability is fairly high V minus lower games you mean PDFs or Windows the problem is that there's still someone who is the last participant and that last participant Moya has the ability to manipulate and seize all the information before them yeah but it could be like it's parallel then there's still some last point of aggregation if you add the V I'm not saying don't have the vrf also yeah Amazo unclear when we're talking about the PDF where you are talking about VF so on top of hash reveal data so even if someone has a type of can hypothetically break the thing instantly the security only degrades to wrandell security but so you so like why not do the most render secure thing anyways then which is to have a deterministic order sort of pseudo random order of reveals as a function of the previous Rand oh yeah yeah that's kind of what you have if you have a like what purports as per forces that are a function in the previous Rando but then you have to wait for you have to wait for a whole for for for a whole like Dynasty quorum to make blocks oh you mean like basically the fact for the new is delayed oh yeah you should be able to do get still get new random numbers at every block no well you definitely cannot get like the VDS root level and min appealability for numbers every block because you have to have this large disparity between the time you're expected to submit and the time the numbers start being used to be yeah there's a large disparity but if you have like and wanted them going concurrently you can always have one the common is that each and every one of those random reveals still it would still on the data would still only be usable after like ten minutes whatever so you're not getting much yeah I don't know there were some talk about how the signatures between blocks say there if there if we go with the attestation design how we effectively do communicate these signatures I haven't thought about too much is that something that does fit into the lid PT P or the PDP layer is that something that any of the teams thought about I mean I guess the nice thing is that it's it's not part of the consensus part of the protocol it's just the networking part and so it can be optimized over time as more and more validators come in I guess validators could theoretically based off of when they know from the shuffle how they need to organize they can like pre organize their networking layer and find out who they need to be talking to I mean they're you know metallic was talking about Charlotte aggregation but there are some designs which are basically already naturally shot at aggregation so if for example we fixed the committee size mm then you know every shard will produce these cross-links aggregating a thousand and then these cross-links get you know put into the beacon chain and the proposer of the beacon chain doesn't have to do the aggregation it's already been done in the shards I'm personally not too worried about it but yeah that's a really cool property of BLS that you can do these incremental aggregations so just do one by one so another thing you can do is just mm pass along the signature and then just keep incrementing by one and kind of around pasen you can kind of pass along an aggregate in a tree structure in the tree structure it doesn't even need to be explicit they can just kind of emerge in the peer-to-peer network right you could have basically individual nodes that's about that specialize in aggregating signatures for like some particular slice of the proposer space and then well if you do that then with two rounds of communication like aggregating 50,000 BLS signatures goes down to the work of aggregating like two men with 200 for this for the same Bell one validator so one thing that I definitely got out of this was that people are interested in these like increment incremental steps right there's like a lot of uncertainty around maybe like the cross shard communication for instance that's like something that we haven't even really talked about outside of like last time you know there are a very fun incremental one use the exact same algorithm as the basically implements a the proof stick you can change using exactly the same algorithm and use this as a plasma chain hmm that's fine using the well the algorithm that like is similar to that we've thought of and is similar to what we've written up but we haven't fully written up yet like basically all that you really needs to know is that like from the point of view of the plasma contract don't think you need to know all that you need to know is they need to have an on maintain contract that can implement verify aggregate VLS signatures which you can already do and then you keep basically that by itself can give you a plasma chain with a decentralized block production and and I don't know at least one kind of incremental thing is definitely you know you have the the peer-to-peer stuff but then also there was this you know Casper FFG with all the the you know votes and those kinds of messages and and definitely learning about kind of doing a beacon chain where you don't actually fill in the details and then you use just kind of like stubbed randomness but getting that FFG mechanism working to finalize the main chain I think it's definitely a good step right because it does give you some more Economic Security it maybe doesn't give you the randomness that you would want which is clearly still being figured out you have some ideas what do you think we should talk about what's you what's on your mind who here thinks we should talk more about Starks who here thinks we should talk more about plasmas who here thinks we should talk more about life a lot doesn't like plasma I [Laughter] mean okay I'm just gonna say plasma is a design pattern which you can use and it is like a there's no okay maybe the only complaint about plasma before I go into my emotional rant it's my complaint with plasma is that it has been used as a kind of like umbrella term for a huge number of kind of vaguely proposed protocols and that is kind of a little bit lame right I totally totally agree with that and it's a lot of marketing I mean damn that plasma implementers call good marketing know uh but like the the I think that the general concept of plasma is definitely a unique thing that you know using a more secure route chain to provide guarantees on transaction ordering on a you know transactions that are not submitted on chain until like the last minute for instance I mean this is this is definitely something that is useful and also like the Merkel proofs and it kind of I think spurred a lot of interest in you know building scalable smart contracts which i think is a huge positive so I don't think that like okay yes it has this hype and yes it has this you know these downsides where people who have no idea what they're talking about kind of talk about it but at least they're talking about scaling blockchain decentralized solutions with you know economic security so that's why I like it but I love you Vlad you two guys who are actually writing the spec in your opinion is are we do we have a general framework like is our do we are we gonna change the cinema like correct correct [Music] and it definitely is a framework so I mean first of all we can kind of think about possible deviations that like could conceivably happen right so one possible deviation is basically going right back to making the beacon though all of the logic of the beacon chain fall right back into the proof of work chain and basically just doing a hard fork of the proof work chain that adds beacon chain logic my main argument against this as basically a number one it would require a heart fork which is like a higher level of float on client developers yeah number two it would be kind of it would be more risky because a lot of our simplifications that we're making have to fairly significantly leverage the fact that the beacon chain has a finality and that simplifies a lot basically for example if the shark chains can only depend on the finalised portion of the beacon chain then that basically means that you don't need to have like funny independent fortress girls and that simplifies a lot of client logic you don't need to worry about it like the the idea that something which was a cross shark dependency of some short transaction is like becomes it becomes rolled back because the only thing that can roll back is stuff within the same chart and it's so it creates abstractions that are kind of nice in a bunch of way and if you fork the proof of work chain then basically it doesn't have those abstractions until everyone agrees to use and trust the proof of stake fortress role so it's like I do I do think that it's that approach is inappropriate at least for early stages but that easy conceivable strategy right so another thing that could end up changing is the proof of stake changes to some form that does not have a beacon chain and uses some fancy Matanga hash graft diggity a TMR copyright patent pending in order to process data yet data on shards anyway so and I personally don't favor that basically because those kinds of protocols tend to be more complicated and don't have you know for choice roles that are you know basically it's like having a be okay final go ahead I just said how because they to be honest like I always feel like kind of an outsider when it comes to sharding I guess my the thing you're talking about is pretty complicated on his own yeah so it's just so like you're talking about that it's complicated okay I see yeah yeah so but like maybe yeah sorry for interrupting in this weird way but I guess the basic question was like before was the we have a general framework and that would be like genuinely interesting for me as well like are we just gonna stick to I mean I've seen the design evolved over time right and I feel like at some point there should be you know we just kind of rely on like certain things being present or not being present early um I agree I'm so I guess like this has sort of me trying to flush out loud sort of the level of certainty that we can have say even over the very general concept of like the beacon change instruction yeah yeah mmm so like so for example we've had a concept of a central B of some kind of central beacon chain pretty much always throughout the entire design right even since like literally 2015 the concept of the beacon chain being temporarily separate from the main chain is a new idea but at the same time like in so realistically for that you know give it a couple of months before it's so it applies but there's a yet like it does see but we did move toward this approach from the other approach for for a reason suggesting a reduced like we heard of movie night I get it but so the question is well I think it makes a lot of difference in people's heads though like a great view that's like the kind of thing so you know it right when you talk about you know storing the like shot stayed on the main chain or storing it on like a separate chain it makes a lot of difference for people even though other things that are set in stone fairly so one example is the concept of like proof of stake where you deposit and then you become about a validator and then you do stuff well yeah yeah the concept that you base you have some form of random sample collection and you can assign to a value at some date over here then validate some date over there and these like random samples are used as as a way of convincing the rest of the network to accept the data yeah so like one kind of like the fact that there is charting in general so even that by itself like so for example I do think that there are enough detail set in stone to make it possible to work on a peer-to-peer network for it yeah nobody I get it so that these things I think more or less everyone agrees with by now right but it always feels like there's like a lot of like really tiny details like in some corner and then there's like more complexity there and even more complexity there and there's just never this thing we can just say you know what this stuff for now dawn is the spec yeah so even if a whole spec you know just part of it so like to be fear even aetherium 1.0 did not end up hitting spec freeze until something like a year after development started in six months before launch though in like there is a rationale for saying that oh maybe we should have like not bothered with receipt routes or whatever and that would have gotten rich and stuck with the POC 5 spec plus security audits and that would have gotten things out faster but that's okay I mean like we do still hear the concerns and you know we are trying I personally think it may be like a good idea to come up with some kind of maybe document that outlines in a very clear cohesive manner all the like all the different pieces right because there is there is this there's first there was the like friendly finality gadget where the slashing conditions needed to be worked out and then there was the you know how does block proposal work and for a while it was just you know proof of work block proposal and we kind of like called it a day but then we realized that the Poisson process wasn't going to really cut it and we wanted these like five-second incremental block times and so going straight to a beacon chain made a lot of sense and it also you know felt good because we are already doing hybrid Kaspar but then once you have the beacon chain it's like okay block proposal where is your how are you going to do block proposal for each one of these shards and then once you get there it's like okay what EVM are we running and what you know cross shard communication do we have and you know and all this stuff requires a really robust peer-to-peer network so I feel like these things exist in some Minds but they're not really very well communicated right now and so you know what I'll do I will happily you know help work on a document to kind of like make pretty pictures and and make it all seem to make sense in a cohesive story because there is a cohesive story that has been going on with the you know development team with you know Vitalik and justin but it's just you know hard because there are so any details this is a huge huge project but we are the Vitalik is the bomb okay so maybe like I mean maybe you're gonna take this as a joke but I guess maybe you should just write a book about it I mean like about the story because that's actually not a joke because we're not trying to say is that you know a lot of these decisions that you guys are making on the protocol they do make sense in some contexts if you have all the previous information if you know what what kind of alternatives have been considered to be fair like you know like the book has been written it just needs to be aggregated I would say you know which kind of gives the criticism we've gotten a lot of places like there's all these III search posts and like medium and like live live streams and whatever and like that you need to be in one place more which we will try to do more of yeah thanks definitely so I guess just to comment a little bit on the way we work I guess we are very much intuition driven and you know that has means that means that you know we don't have this storied framework and we're happy to to pivot quite fast I guess the advantage is that we get to really explore lots of different design paths and so you know there's this feedback loop where our intuition keeps on getting better and better and it feels like the dark rooms that are unexplored and in the design paths are starting to one by one get eliminated so there's definitely this feeling of progress another thing is that every once in a while you know we make like a 10x improvement and then these 10x improvements kind of compound on each other so you know at the station's BLS proofs are custody you know this may be each kind of order of magnitude improvement and so I think there is value to to try and get as many of these as possible I guess once the dust has settled and we feel comfortable that we explored a lot of the design space and and that our design solves our requirements I guess there will be a phase of a peer review of simplification and then at the very end what I'd like to have is kind of formal proofs maybe have have some sort of formal model and work a little bit like what Cardno is doing with maybe slightly less pedantic and actually write proofs that there are design is its coherent and then maybe even go down the route of formal verification for specific components I think G de and we can take it one step further with other components one thing I like doing in protocol design is trying to see if we can write down a list of desiderata and then just basically derive the protocol from the desert otter and show that it's pretty much the only option and like there are some ways in which in which we are getting somewhat closer to that so like for for example the like there's results results about properties that you want from the fork choice rule there's results about what we want in service of efficiency there's results in terms of what we want in terms in terms of predictability and if we can make kind of like better and better arguments over time that basically show either this is the best approach or at the very least there is nothing that can cut that that's not within reach of implements ability that's efficient was substantially better than the approach that's when you ends up getting more stability so I guess one example of that is like if you look at proof of steek research right I feel like it was very kind of floating in the air about like two to three years ago and what we once were a whole bunch of ideas but now you know like we have the Casper FFG family we have the CBC family and there's a formal proof set that FFG works there's like a safety proof of CBC but not yet aliveness proof ahem ahem right okay well if you have a good full life oh you do you have a good the the know that was a questioning tone of confirmation not a questioning tone of suspicion and there's also proofs that like both of these are in some ways within you know something like twenty percent of being optimal so once you get and once you get to that then you do get but that does basically mean that things are kind of like much more stony in that way right the next thing that I personally want to see becoming more stony is like proof of stake for choice rules so basically prove that you know there is basically one like there are choices of structure but they're basically as one and only way to make a good fortress well that's out as wide as a bunch of properties right yeah goes like that's pretty much my philosophy too right though a ghost is the optimum and we either use that or finds like V Revere and good approximations for it so like if we can so I like to set the for choice rule in Stowe and and possibly even formally prove properties of the fortress role so like one example more than fifty percent plus epsilon of all of our daters assuming everyone is offline and you control fifty percent minus epsilon another one in my mean might be properties about what difficulty of censoring selectively right so and you want these results to be ideal yes independent of the random number generator as possible so if you can kind of prove move toward proving results like that then that comes closer to basically saying okay this is a fortress rule and we know for a fact that we have that we can prove these properties that it's impossible to get properties that are asymptotic way better and so we have something that we can kind of settle on in this room it's not going to change I have a question for the protocol designers so what will be like the perfection in your mind imagine if like computing the timestamp of a piece of data where of when a piece of data was published was like a mathematical function that you could evaluate so you could compute like when a piece of data was published to the Internet at the same we could compute its hash and then we would have like in said that we would not even need consensus and we would have a hundred percent fault tolerance that's like optimal unfortunately we're not gonna get anywhere close to that but you know I feel like the in general in a very wide sense right the optimal protocol is one that has the properties we wants to a reasonably close approximation and where we can prove that you cannot get better properties without sacrificing something else that we care about even more and I think that like to build on that at the same time perfection in terms of the process would be also like defining you know step by step how do we actually get there and you know implementing each one incrementally and getting close enough that we can support a decentralized application ecosystem and not like we don't need the absolute you know highest TPS we just need you know just enough at least for now to get us to the next step and you know make developer experience good enough and then pass it to Danny and to keep these components as modular as possible as we discussed earlier so that we're not stuck so we don't have a protocol that like almost is we want to do but we you know we wish they did it this way or that way so to keep things I'm very very modular and definitely uh-oh just yeah and also like transaction security like what I really like is I like the idea that you know you can sign a transaction and depending on what the you know what kind of transaction it is you get different levels of security and you're okay with different levels of security and like the more you wait the more ingrained it gets and the you know if you sign it immediately and it's a state channel then you get like some level of instant but then you know so I like these kind of traditions of security so what is a good enough developer experience because I think a lot of developers don't really care about the details of the consensus protocol or whether it's five second lapse for 10 second bucks I just want to know how painful is it going to be to build adapt that scales agreement um so one example of a developer experience that's definitely good enough at least from the point of view of a blockchain is something equivalent to what the current etherion blockchain provides obviously you know I could Plus somewhat shorter block times if we if we can get them so the goal of shorting from an experience point of view right is not to make the experience better it's to massively increase capacity without making the experience much worse and if if we can get if we cannot decrease developer experience at all then that's the obvious optimum and if we can in then from there it's a kind of bargaining game of like well you can decrease it this much maybe you can do a bit better but the but at the cost of a large number of changes to the protocol but then if there was a large number of changes are gonna be our extreme complexity maybe it's better to do it at layer two from a rollout standpoint my personal view is that we want if the rem 2.0 it to be something that like actually can promise sort of higher levels of immutability in certain respects so basically whatever guarantees we come out with on day one should be guarantees that were really confident about and if there are guarantees that we're not confident about well then we should just like roll out with those features disabled and then add them on when the research gets done and we can become confident so that's part of my preference for example for cross links and I cannot want not launch look very strong a cross short communication capability or possibly even like insured cross contract transact a synchronous transaction capability immediately so that we have more time to choose what they're not willing to commit to synchrony I think also for a developer experience I know this is a sharding workshop but it's certainly important to just like reiterate that every single person here is like smooth some of the most knowledgeable people about aetherium and so any work that you can do to like you know spread the information of how to build decentralized applications and how to reason about them like we have this adversarial thinking that we've been talking about this entire time or it's like okay if the attacker does this what do we do how is our protocol robust against these kinds of you know manipulations and so this is something that I don't think people as application developers on the broader space like are really that's not front in their consciousness but it is front in all of ours because we're living in this decentralized peer-to-peer kind of system and so I at least one of my biggest things it's like okay how do we you know developer tools is certainly a key aspect here but also just like communicating the vision and communicating the you know ways that we develop these protocols and that's why I like what I'm really interested in is like okay the sharding protocol has a thousand different components because it is like the using the bleeding edge of decentralized tech but then each one of these components can be used for things like plasma change use for things like state channels used for things like you know reasoning about other economic mechanisms that even exist off chain that exist in centralized servers so it's really this mentality that I think is the most important and so like let's develop starting let's build these protocols but then let's also like keep decentralization alive the more design things we kick out to layer to I guess the less usable the system is by developers out the gate and the longer it's gonna take for us to build up the the tools and the ecosystem to allow the developers to like be able to cleanly work in the shredding landscape and I I think it's it's a it's a trade-off certainly but I think that's the best way to manage the complexity at least from like a research standpoint if the research isn't there then kick it to lay or to for the time being with knowing that there's probably gonna be growing pains and people transitioning and trying to address those earlier rather than later in terms of a developer experience I'm actually more domestic than metallic I think the shouting developer experience will be much much better than what it is now I mean just the fact that we have five second blocks with low variance that we have finality that we have a really good random beacon that will have a better VM and probably other things that I'm missing will help I guess another thing just to give an example of what Kyle was saying is that the the research that we're doing for shouting like it's preachin Eric it's very modular is the if research posts tend to be like very small ideas and just this morning tribute announced that they would be using proofs of independent execution together with their forced errors so you know that's a piece of sharding research which is being used at layer two and so I think we're gonna see more and more of that happen as soon as we educate you know the developers on on the research that has been happening just like one one example of this kind of like layer two layer one thing is that like there have been multiple decentralized Twitter's that have come up on aetherium and and exist on aetherium and twitter is definitely a good use case in terms of you know we do want some kind of like decentralized censorship resistant stuff but if we were to like scale this decentralized twitter we clearly can't publish every single tweet on chain we don't really need like everything to be on chain for Twitter if you use hash links then you know the ordering of your tweet for one particular user you have private keys and you do need pieces for that for like identity and for like sending money and for you know putting bonds for your tweets or you know there are million mechanisms that you can use on aetherium but it's like developer experience is also saying okay this is don't necessarily just like put a tweet in a transaction unless they're there I know to Vitalik likes putting tweets and transactions at times because we don't have like the scale yet so I'm gonna get in trouble but nonetheless keep it off chain and make a good user experience I think the use case for you frog what did you were shards before they become usable for code is that even now isn't even just Twitter I was actually thinking about storing the user interfaces and like other contents were weighted to decentralized applications so like basically if people want to use taps and like either a swarm isn't ready or they happen to want something which is like even higher guarantee and availability and then swarm then they can just like shove the data if it's on your 100 kilobytes or whatever into a shard possibly if it's even up to a megabyte you just have to pay more so now the reward in the shot is no longer the virtual Easterns right it's the real research we mean by this back to the in Taipei the reward of the shot China actually not so in the current spec so far all of the an incentive accounting happens on the beacon chain and like what's drawing is just a stub right now the eight the intention is definitely for beacon chain deposits plus the rewards to be what Schwab will into shards and for there to be a money about eventually a pathway for moving either from the main chain straight into shards so like virtual leaf is sort of really thin that way yeah I have a different question okay so you guys like just because Swan just come up it was kind of a thought from this event that it's funny because the the swarm team has been doing its own research also on things like proof or custody for a long time and it's actually supposed to be like a reliable thing to a reliable system tour to store things and ensure that they stay available they do have like a messaging solution available and things like that so how are you guys thinking about you know maybe collaborating with a swarm effort more to maybe use it to just you know story of stuff in the center stuff yeah and I think one very natural area of collaboration is that we do need a storage layer for blockchain history and we do need a storage layer for receipts and we need a decentralized search engine for receipts because like ultimately searching bloom filters for topics is what can oh we're close to enough so like I think that does naturally form a kind of one of the initial killer apps for this form yeah but then the question is because I mean as far as I can see in in in the in the shouting protocols it does he require built in proof of custody to ensure that like immediate histories life couldn't that kind of facility also be provided by a swarm then I mean it was the proof of custody anyway um so I think like the main problem is that a proof that a data file has a proof of custody needs to be included but first of all it needs to be included in the consensus layer and second to get the guarantees that we're looking for it has to be specifically the randomly selected subset of validators yeah so our goal with the kind of random sampling the plus proof of custody and plus like proofs of execution is to try to move the model from being honest majority to being or for being to being kind of like uncoordinated economical irrational majority and so I basically unlost a very large portion of participants are in a court needing to attack then it would be in people's interest so participate in ways to keep the system running safely yeah okay so anyway III really think like you guess you're considering using SWA more because I don't think it has like interesting you know properties that might help you agree we should definitely talk more so one cool idea in terms of making use of the shards before the VM comes out is in terms of having a plasma chain to pay for transaction fees out-of-band so I mean that's even something that I think would be very valuable once we have an EVM in the shelves because who wants to have you know balance on the thousand shards just in case I want to make a transaction on this shard or that shot so I think it makes sense to have one or even many plasma chains where you can have a single balance in Eve and then in the plasma chain you can say I will pay the first proposer who includes this transaction on this shot and that's how much I'm paying them so yeah that's a way to basically get a initial value from the shots even when there's no EVM to incentivize the transaction inclusion and it's also something that will be valuable once the shots have an EVM just to kind of like expand on that a tiny bit the biggest problem with plasma is this data availability thing right you don't really know if the plasma operator has published all of the data for the block just they could have just published the block header or a miracle route and like missing a lot of transactions and so you can use this sharding infrastructure which is basically a like short-term availability solution so you know that this data is downloadable or it will not be included in a shard you can use that for a plasma chain to like give the guarantees that you you know are missing and in most constructions and so you basically what you're doing with that is you're mitigating this kind of exit like not yeah this mass exit phoner ability which is not as bad in certain circumstances but essentially you don't want your plasma operator to be able to force users to exit ever because that is just like a griefing vector so you can like kind of solve this which is cool yes what's up hi so what are the the darkest rooms left to be illuminated when it comes to shouting you know what are the the biggest known unknowns good question so what one kind of somewhat fine wine is like what level of efficiency first darks is actually possible and the ends basically like that's kind of like a positively meaning darkroom because if it's possible to get Starks down to some like absurdly low although size then there are way more applications to use them for than just aggregating signatures and doing me DFS so for example if you are flying block correctness recursively verifying block correctness verifying block availability and then we can get rid of fraud proofs in many cases and one if you have like extremely perfect kind of like instant extremely fast a general-purpose succinct proofs then you can like that massively helps a lot even even I scalability and Link it opens the door to super quadratic scalability in a bunch of ways another another dark room that's kind of more on the darks on the dark side of darkness is basically the way in which the kind of community will respond to the economics of proof of stake in practice like basically because like that you know the economic model is definitely one that has been kind of philosophized over very heavily but it has not been tested and like the number of people who have worked on proofs take with math equations as definitely it's definitely the case that I think even many of them have not asked the question of like given the current incentive structure do I personally feel comfortable with like shoving half of my offensive this person into this particular model and that's so the we you know are there centralization incentives or they're a do the anti centralization incentives actually work but will everything just call us into like two pools that are controlled by BitFenix and like whoever else it's up running you know what the EEOC ellicott notes or whatever thank you like we have sort of philosophically come up with you know a bunch of mitigations and a bunch of ways to I can make the out of the proofs take more finally in practice but like this is stuff that has not been run in the wild and so what has been run in the wild there is a certain degree of unknowable Ness that's not gonna be crossed so so these things technical questions they're muscled sociological in that sense right like there's there's technical element elements to them so like for example the feasibility of running you know certain kinds of centralized perversity questions in practice but like it definitely is like I think what a lot of the extent to which today proof of stake will succeed at being decentralized as definitely as social as it is technical like it's basically the the extent to which centralized providers are capable of providing more convenience and the extent to which users value this convenience and like I do think that the centralization in a decentralization of crew stake battle will be fought along those dimensions even more than a lot along the economic ones and that's that definitely is like that kind of unknown that can't be as easily put into equations another one is also incentives that have to do with capital lockup and how the market will deal with so capital walk-up evaluator swats and how capital lockup evaluator swats will end up being priced and like how people will choose to participate in that versus participating in by say putting their deposits behind like state channel constructions or interactive verification constructions and the extent to which like how those will interact how those will compete with each other I mean on the intersection of making sure the stake is properly decentralized and of darkrooms I guess one new dark room that was I pointed out to me recently I'm doing this event was is our protocol friendly to decentralise taking pools and it turns out that maybe not especially in regards to ran down so you know with Randall you need a single entity to to reveal the commitment and we're gonna have a slashing condition so that you don't reveal too early and and basically break the source of entropy but if you have this unique revealer how does it play with decentralized staking pool that's still an open question in spy generates a value excise secret chair city and and what gives participant GA like X IJ and then participant G gets all of the X IJ pieces and then like la garages or Boyd's them all together and then you have like a lipstick curve verifiable of your verify ability on all of that and this all happens off chain like it's a primitive and academics have a name for it but like at the same time it is hard okay so you have this scheme to agree on the secret right but you also need to pre-compute the whole hash chain okay so we need to we need to change a protocol to be friendly okay one thing it will I think reduce the or Surya will no it will reduce the difficulty of creating centralized staking pool solutions that have some degree of trustworthiness which is both somewhat worrisome because it all increased the extent to which people are willing to trust them but it's about also really good because basically even if like 40% of all the staking he attends up being walked inside one of them it would still be like because of the trusted hardware itself it would still be very difficult for anyone for anyone to use that power to do anything bad definitely cannot use trusted hardware to commit to being online so I mean phil has a question I could say a dark corner I'll just say while it goes just a like cross shard communication developer experience like that is a question for me and like the actor model if we decide that asynchronous calls between contracts are the way to go that's another big question right how do we actually make that a nice developer experience in the migration path for a solidity and Viper to that is also another question so it's basically a lot of work not like technically so another dark room is like perhaps for migration from this shorting spec two radically different shortening specs that may be better so one no like so like one example of this a super quadratic shorting that might be enabled with in beast like Starks and like be like very efficient proofs of correctness and proofs of the availability one example of this as like various kinds of dynamic shorting schemes um like I would personally favor just like saying there is an entire category of complex spooky stuff that's not allowed for aetherium 2.0 and we should just be okay with waiting five to ten years for it to come in if your iam 3.0 and we should be willing to say that you know something like ten year at five to ten years from now is the expected release date of etherium is 3.

0 type thing if we want to actually do if that's something we want to actually do but there are like they're definitely are technological and know instead of going in that direction so one fun thing that Vlad and I were discussing related to the trusted Hardware comment earlier was that you could actually build let's say a pool for for storage and then not have to reveal the s in the proof of custody construction to whoever's running the pool plus use availability bonding to make sure that essentially like their risk of being offline is greater than yours of being slashed so I guess my question is with the fact that it seems like new technologies can always sort of alter the internal incentives of the protocol in ways that we can't predict do you think if your iam will ever be done done like like set in stone and or is it something that's constantly going to be evolving and iterate onion realistically I personally do want it to be something where the development can slow down much more over time another thing worth pointing out is that a lot of these constructions are in some ways stopgaps until what I do think is a 3.0 utopia which is basically using a general-purpose succinct proofs to varrock fully verified block validity and then use of the arisia code construction to allow a kind of same random sample checking with the availability and when like basically if with that like that does like that does solve a lot of the problems that we have right now another thing is that at least I'm trying to design the protocols are we to have kind of redundant components that try to ensure the correctness of properties and redundant ways so one example of this is that for shard block validity you have you you have the random sampling mechanism you have the proof of cop proofs of custody with validator bonds you have the potential for various forms of client-side data availability checking so like the goal is definitely to have multiple primitives so if future developments end up breaking one of them and the others are still standing just in terms of risk of D solidifying the the spec may be external research from other teams so I know that you know there's Definity that's doing research in Java in Kedah no I think here of course blad that's internal yes I mean what I what I gather is that for example Definity in Kedah no they they kind of work privately and then once they're happy with the ideas they release a white paper and it's possible that in one of these white paper there's gonna be a 10x idea that we want to incorporate and that might you know lead to a redesign I'll repeat a comment which is that we can kind of balance the extent the possibility of good ideas in not fully but in some respects if we prove mathematical bounds on optimality right so like one very simple example is if we look at the cost of processing a certain number of validators then we know that like we did the math and if you look at a BLS aggregate signature like basically the bid field is already much larger than the signature and so we know that information theoretically it's not possible to achieve more than like a few percent more games within the same structure now granted you can try radically different structures like finding ways to kind of short the entire consensus but then for that the other thing that we can do is we can look at like basically proof stuff that let's say we can look at the arcuate of kind of how much we'll ever need so for example the current sharding spec can handle up to four million validators and I think a reasonable upper balance for how many validators we definitely don't need more than is basically the world population so realistic way around like eight billion or so and even with much less than that you know you still get very high levels of decentralization so eight billion is definitely a number that we could get to with like Moore's a decade of war as well all by itself if we need to right so what we can we what if four of the eight billion or Joe Lubin though well that's something that so that's something that cannot be improved by increasing the decentralization capacity capacity of the base layer blockchain but Hills but you still get slashed if you're evil no matter how rich you are ooh what if we discover a technology for slashing Joe Lubin yeah what was it they I think they tried one and they're shutting it down and updating the Constitution if anything Joe Lubin would be electing all the block producers in that system right so so you might not want to implement it no II we love Texas I'm personally excited to start building this spec and you know being flexible as it grows but starting to get it out the door I'm feeling somewhat confident that that's that it's time and I'm feeling good about solidifying portions of the spec and very much communicating and talking we shall way about I'm sorry I keep talking about this peer-to-peer network but other things - not just that also the the finality gadget with a concept of a beacon chain and coming up mate I feel like there's an there could be an interesting way to like do that where we don't actually where we can have like some kind of test net where we don't that we don't have to pivot away from very easily because I mean the finality logic is still there there is a chain that exists it concurrently that is the big decision like do do we somehow go back on this beacon chain idea I think is like a definitely a key thing that's in my head and I don't see why we would at this moment so it seems reasonable that the beacon chain will survive in some capacity and so if you have a chain that finalizes another chain and on a peer-to-peer network that is charted you are now very very far away I mean very very close but far away from the ultimate end which we all will face that was weird that remind that was the title of one level of a video game I played like 10 years ago where one of the levels basically had the start and the end be like literally three meters away from each other but separated by a like a basically a cliff that it was just too long to jump over and so he had to do this really big long journey that's what many hours it's a fun metaphor yeah we're already at the end if you really think about it yeah so I guess so serene it's a very transparent discussion on the east research that Eastern on the keytar we have shouting try no and so many blog posts the last Twitter lunch with Alex Twitter and that's all the news oh it's very boring and so I like to think old attendants coming from far away or just in Berlin but and sacrifice your Sunday joining this meeting yeah and the last one is that and we will have a dinner about 10 min after 10 minutes and then again and we think status yeah the wonderful life PR thing and of course is our foundation my foot son [Applause]