Proof of Stake Panel Discussion - Silicon Valley Ethereum Meetup

Transcript

and what are the um conflicts and things like that a short introduction of Dominic um or you um yeah hi I'm Dominic I um work on decentralized protocols and crypto generally uh I work for a comedy called string labs and we have two projects at the moment one called Affinity which is uh kind of distributed virtual computer with a kind of different slightly different Focus to ethereum and uh I think called fi which is a kind of decentralized version of Commercial Banking all right so vitalik already mentioned that some interesting thing that is part of definity is is um BLS signatures but we will go into this in

in a moment just to get started so um I want to just quickly uh from each of you throw out the number or or short answer on those questions about um your system so your version of cper version of Casper your version of infinity and tenament um what what are properties on those questions so first question is finalization time what do you assume can you reach uh 5 Seconds um initial version is around an hour and I would I would also make the make the claim that it's a not realistic to claim that you can do less than an hour because there's within the next few years there's there's a risk of like protocol issues hard Fork software bugs

and so forth and I'm not sure that like a finalization time that's less than the amount of time that it takes for like developers to figure out what the what a bug is is even meaningful finalization at all okay we will have an interesting panel yeah I mean um um nodes know when they decide though so if just because you've decided something on your node doesn't mean that your node won't get patched later and therefore become a different node you know but like a decision is meant to be finalized from the point of view of the software that's making that decision and so even though if in practice it isn't finalized the software thinks it is and so it counts uh but uh in my world right now I I'm my version of Casper is a

synchronous which basically means that I don't have any livess at all I have like no I mean in practice I don't I don't know probably be pretty fast but but in theory I have no guarantee at all that we we will even come to finality because and an asynchronous network with faulty nodes that's like the nature of flp um you know this flp impossibility result um so it could take forever in theory uh but can also very happen very fast very fast in uh uh but you know there's no there's no like theoretical argument for what I can give you there um so we we have um it's just a blockchain running on a single data center that's going at really you know

it's finalities is very fast on order of um 200 milliseconds but we're not even trying to make it fast we can go much faster than that but for a global so it depends on the number of validators and how Geographic distributed it is um for the global blockchain that we're trying to create we want it to be the most secure blockchain ever um we're targeting a finality uh transaction finality or block time of uh 3 seconds and um we'll be able to support more and more validators in the future as well okay we will go into this deeper but I we'll go through the other questions um what is your expected number of of validators um well you you aim for a network of

more than a million um so all of the protocols we work on uh before any kind of research or design work goes into them we always assume that the network has more than a thousand validators but we don't see validators in the same way as um traditional proof of stake um projects um because if you want to create a scalable network uh you need to actually think about computational resources so in actual fact you need to create mining identities and you need cryptographic ways of determining whether these mining identities are actually performing the tasks that they're supposed to do such as uh keeping some unique copy of state right so um validation is one piece of

it but actually if you want to create a scalable Network you've also got to think about computational resource it's not just enough to say oh this guy's deposited some stake and therefore he's going to be able to mine a block this many times that kind of architecture doesn't in my view lead to to good scalability or a good doesn't provide a good foundation for creating scalable distributed virtual computers so uh you know it's a slightly different uh a slightly different approach um of course you know these individual processes with with mining IND densities do have responsibilities that include validation but you know one of the other um I mean a lot of these questions are you know difficult to answer directly because you know you ask what's the time to finality

well that that means that's a probab that's a sure that's a probabilistic thing right you have to you have to actually put numbers on it to be able to answer it but um in in our case you know we have a scalable validation lay you cannot actually have an infinitely scalable virtual machine without a global validation there you it's a fallacy that you can do validation on each Shard individually and you can maintain security you have to have a global validation there now necessarily if you're processing billions or trillions of transactions a second and your your network stores exabytes of State there's no way each process can validate every transaction or even a tiny fraction of the transactions so in fact you have to have some mechanism for partitioning validation so the kind of

conventional idea of uh um validation or everyone being a validator of some blockchain um it's very sort of you know it's kind of like that that works with a kind of 2008 kind of view of of blockchains as a you know where everybody reapplies every transaction since Genesis and checks that they've got the same set of unspent transaction outputs right but when you're talking about um you know scalable virtual machines that that kind of thing just doesn't apply so you know you can talk about how many um uh how many processes you have in your network and in our case we you know look at protocols that can um cope with any number but then although they're all

validating things you know typically an individual um uh State transition would only be validated by a subset which was determined by a random Beacon so it's not it's a kind of more nuanced answer I suppose okay um well to answer the original question I'd say in earlier versions 10,000 in later versions Millions um the other thing I'd point out is that in uh I think in like later versions of scalable systems we're also going to see multiple classes of validators and like particularly going to see multiple classes of validating Behavior so one of the two most important distinctions I think is between validating data and validating state so in like Bitcoin and ethereum and like most other blockchains so far

like validators basically do two things at the same time or one of them is that they say these trans look here is um a block header and a crypto Merle points to a bunch of transactions and I certify that these transactions exist but then it also says look you know I ALS either here's a state route and I certify that this is the result of applying all the transactions or even in bitcoin's case it certifies that all the transactions are valid which actually is a claim about previous state as well and I think that you can actually design much better scalable systems in the long term by separating out um data ver uh attesting to data availability and attesting to the result of applying the data so like one example is that you could imagine having this shorted

network with like a large number a large number of shards and you could imagine validators being like almost immediately reshuffled around and told you know here come up with a data block for shard 39 now come up with a data block for shard 387 and because all they're doing is they're attesting to one two a few particular pieces of data they don't actually have to like download the the state of sh 39 in order to say anything and then you have you can create this like really optimized in like high performance data layer and once you have data the Assumption of data ability as a base then on top of that it turns out you can you actually can create very secure mechanisms for doing State calculations like even like if you're willing to accept livess assumptions

then if there's even one on a state validator then he then that one on a state validator can pretty much over like eventually prove that like all the other state validators on the network are wrong and like those like that's a property that's potentially very powerful can achieve like very high degrees of robustness and sec security and like also really help make Crush short communication much faster than you know the 12 hours that I was uh talking about before yeah so kind of echoing some of italic sentiment I feel like um the set of noes who are validators is could be much larger than the set of nodes who are forming consensus um so like to me like the biggest set of nodes the ones that

guarantee availability and then there's like noes that validate and then there's noes that form consensus um and in like my opinion uh we don't actually need that many NOS forming consensus as long as we have a lot of noes validating uh basically you know validators will make make sure that like your transaction receipts are are correct in terms of result correct executions of the virtual machine but and the consensus forming nodes uh kind of engage in this process of finalizing so for you validators everyone who runs a full note and consensus forming are those who have a something at St so validators have a special role in the protocol in the sense that they have deposits and they can provide these signatures on blocks that like are economically meaningful uh rather than

just like full nodes consensus forming nodes don't do have economically meaningful signatures in your system no the consensus forming nodes are also validators they're their subset of and and and what makes them special uh the consensus forming ones yeah they're actually the ones that are involved in forming consensus they're the ones who uh are are placing bets but but if validators have something at stake why why are they not part of oh because like uh you or how can they lose overhead there's there's there's overhead there's like quadratic overhead in the number of nodes for the finality cycle um and so like it's it makes sense to have there be less nodes converging uh like every validator could potentially

be part of the consensus forming yeah although if you have if you have a separation of roles uh you don't you don't need that just to to uh sure yeah complete this round um okay so for me a validator is only is a consensus signer and I think the number of validators that we need um is really dependent on how fall tolerant we want it but like just because we have a lot of validators doesn't mean the security is proportionately that much better I think the security is maybe like log of n like proportional to log of n where n is the number of validators so if you already have a hundred like a thousand isn't 10 times better maybe

it's marginally better so given that and the and the price of running a machine um and and and the the cost of um where in bft algorithms more validators means the whole system slows down marginally more I think the sweet spot today is like 100 to 300 and in the future it might go up to a th000 soon might even go up to 10,000 but probably not much higher but okay on the other hand I have this notion of um validator Alliance where a group of validators decide to validate not just one blockchain but a whole list of blockchains so in that case um one validator would have like a a data

center rack full of blockchain um servers so you know this complicates maybe we have a difference of lexicon here thank you all right so next question will in your system are there block reok or or do you if if it so um you need something that's consistent to create a scalable uh decentralized Network because uh you know there's going to be some kind of top level record of um agreement right it's not consensus actually consens blockchains don't reach consensus anything that's got a sort of probabilistic element to it isn't

consensus consensus is a protocol which you can run and and it decides result and everyone can stop doing it in a blockchain if you stop then someone's going to make a new longer chain or something like that right but uh you're going to have to have some top level record of agreement and that's going to record State routs and this thing is going to drive the rest of the network right so imagine if you had uh you know a million machine uh Network providing a scalable virtual machine right effectively by by decentralized protocol execution um you know if that top level thing was reorganizing all the time you know there'd be all kinds of other structures that were driven by that top level

record that would also have to reorganize so it would be very very difficult to um design protocols that could reorganize themselves um in in sort of um sync right and it would also be very inefficient so uh our solution to this is minimally to have a Incorruptible in unmanipulated unpredictable source of Randomness that just is absolutely UNF forkable and all of our protocols depend on that and we do this using something called threshold relay which involves um groups of processes producing uh unique deterministic threshold signatures right

and these particular kind of threshold signatures are interesting because there's only when the group produces this signature right there's only one possible signature that can be produced Bo the group has a public key and let's say you have a threshold of 50% right like in Bitcoin you require 50% say 50% of your group it's a bit different but 50% of your group has to be correct be functioning and they can produce this signature whichever 50% of that group participate in creating the threshold signature it's always the same and clearly it's a random number if it wasn't a random number you you'd be able to predict what the signature was and anybody would be able to sign right so you can imagine a system where you know one group produces a threshold signature this selects deterministically selects

another group and that next group has to sign the threshold signature of the previous group and so on so you get a deterministic um chain of Randomness that is released on the agreement of the each of these groups and that's UNF forkable right and the the interesting just quickly the interesting just to give you an idea of how robust this is um if you had 10,000 processes right and let's say 30% of them 3 % a third of them are faulty so you got 3,333 faulty processes within the 10,000 which is already pretty bad if you if you take a random sample of 400 right the chance that 200 or more are faulty I not

functioning down controlled by the adversary is 10 the minus 12 which is a very small probability so you can create this um chain of Randomness this completely deterministic unmanipulated able unpredictable unfor right and you can use this to drive your network and it turns out that once you have this Incorruptible un manipulable unpredictable unfor forkable chain of Randomness being produced you can then build all kinds of very sophisticated protocols on top of it and that's how you get scalability and I believe that it'll be proven um somehow through thetical computer science there is actually no way of creating an infinitely scalable virtual machine

decentralized virtual machine without such a source of Randomness just to give some context so vitalic mentioned this earlier um for proof of stake systems we need the source of Randomness uh problem is if you if if you just say Okay um the last one who submits the block um this submission of the block will generate the new random number well you can withhold your last piece of information the Block in this system in the BLS uh threshold signature system the beauty of it is that that as long as one of the remaining parties is available or let's say you have 50 out of 100 um and you are at stage 49 they're not the number 50 needs to be available but just one

out of the remaining 50 parties needs to be remain uh available and you still always produce the same random number so question to vitalic and Vlad if we have um this system and it seems to be superior why not use it for Casper I mean personally I'm actually just like I guess intuitively like I really love this idea that I can make it make ethereum 2.0 rely on literally nothing but uh random oracal property if sha 3 as a security assumption so like no noptic curve curve graph properties like no nothing else just sha three and I mean aside from that I think like the tech is really

cool um well so I guess I have two things to say one of them is uh the current spec of CAS I'm working on doesn't Fork after finality but before finalized blocks for non-f finalized blocks uh there can be reversion uh and the reason that we we have this is basically that if a certain proportion of the nodes go offline um we can still produce economically meaningful commitments even though we don't have um finality in the in in the full sense of the word um but the and and this kind of raises this qu point about the threshold signatures and kind of more generally about consistency favoring consensus

protocols uh is that they require they do require this threshold of nodes to be online and one of the big uh design requirements that I have for Casper is that of a very large number of nodes majority of the nodes all but one node really strictly speaking uh should be able to fail permanently and the system should be able to recover uh without a hard Fork um and this and this is not a property of any that requires a threshold for any blocks to be produced for any high level Rand Randomness to be produced or or or anything like this I think here we can go deeper into it so this um question of availability or consistency so you uh what What's what would be your opinion should should the blockchain continue if there's only one

uh one validator online or no I it reminds me actually of a conversation Vlad and I had late at night I think in e in Berlin like two years ago or year I don't know anyway and the AR arent was you know I was arguing for for consistency and he was arguing for availability and I think I think the argument went blad's a great troll he ended up saying that he wanted his system to be able to record his Starcraft scores whatever happened right and um but you know I mean I from my point of view I think uh you know I think systems should stop working at some point if there aren't enough participants online I mean one of the great weaknesses of uh their in my view is that it it does continue working so

if you imagine um there was a some some kind of political tensions in the South China Sea right there's like a cyber warfare button that both China and America have to prevent their you know secret Services disrupting each other's infrastructure and they'll press the button and and the the link will just break and then there'll be just some diplomacy and you know after a you know a week or hopefully whatever you know it'll be resolved they'll press the button and the internet will come back up meanwhile of course there'll be two forks on both sides of the Pacific right and whoever has the most hashing power um will ultimately be the winner but I don't think that's a good situation right because you know somebody's you

know there's going to be a half the half the world you know effectively is going to lose and we don't know who it is it depends on who's got the most hashing power but that doesn't feel like a good system to me so I would rather that we designed consistent systems that are very fault tolerant but you know at some point they're going to have to fail right so I think if you can withstand you know almost 50% of the participants being offline and still work that's pretty good and that should be good enough and actually if we get to a situation where you know so many of the so much of the networks down it would be actually sort of better anyway to stop for safety purposes right that' be my kind of preference first J should system

continue 50% of the that down or not sure um I think that depends on the type of application you want to build so like for a kind of application that only deals with like transferable tokens for example which is what we're doing with the cosmos Network you can just have a global um or like a a virtual Center um that acts as the center around which many other blockchains connect to as side chains and if there's a Global Network partition even though the center will be off all the periphery side chains continue to function and if they're Regional then all the better right and then when the network kills um people will be able to move tokens again but uh meanwhile they can use lightning Network or other means or not even or

just stay within their blockchain so that's one way to mitigate um I I want to go back to address something about Randomness but okay okay maybe shortly vlad's Starcraft response or yeah so I just want to say that um you know the I kind of agree with Dominic that the way that Bitcoin works today isn't great because people on both sides of the network will get blocks and they'll think they're just normal blocks and they'll Count Their six confirmations and then they'll like release funds or something um I think the the the the nice thing about like the thing that I'm trying to provide with Casper and the nice thing that about uh proof of stake protocols is that you can tell how much of the stake is on your side of the partition and so you can tell uh you

know even you can tell that you aren't safe because it's not not not enough of it is there for you to be safe uh but still you do have uh economically meaningful commitments from the validators who are on your side of the partition they will be bound to uh not equivocate and not make messages in a certain way that doesn't include messages that include your transactions later you get you you get real guarantees uh even when you aren't safe uh from the point of view of um you know finality you just have to make sure the validators won't fight each other out to the death when it merges no you just give them you give them a protocol and then they just use the protocol your response to Rand the randomness problem oh yeah um so so

Dominic has a great way of of of solving he knows very well about uh there's two ways to circumvent the flp impossibility Result One Way is by assuming some notion of time and the other way is with having a common coin or a random number but um the reason why I avoid that is because the cryptography there um is unproven it it requires um the Diffy Gap Helman assumption which I have no idea but I do know that we can create Lamport signatures which means that tendermint is a system of consensus that works with nothing but hashing right um so and going back to your allegation that you can't scale ethereum up or and general

computation up um without a random number generator I can conceive of a way to do that by forking the Cosmos Hub um to connect to many other ethereum side chains and delaying packets between one no to another to create some room uh for U contesting results and I think that scale just fine I actually don't believe either of you I I don't think anyone can scale a a decentralized system infinitely if you are also giving consistency properties across the whole system um so just to respond to a bunch of stuff at once um I think um look just to reiterate what Vlad said and one of

the nice things about Casper is that I feel like it provides the best of both worlds in that you have an availability favoring backbone but and you know there's differences of how this can be implemented but but on top of this backbone you have this finality Gadget and so if you have a chain where if you have most of the validators being present then the finality Gadget keeps on keeps on triggering blocks keep on getting finalized and people who really care about their application needing finality can just watch for finality and not do whatever they need to do until finality actually triggers but if you know the chain does split in half then the two chains continue but this finality Gadget never triggers now the answer the the point from a while back about well aren't

validators going to lose money because they make bad bets and eventually one chain is going to win so the answer there is basically that because the finality Gadget only starts when it notices that more than two-third of validators are online and it only sort of starts spiring up exponentially if at least two-thirds of validators are compl placed in the process so if there is that kind of fork there then basically the only kinds of bets that validators are going to make are Bets with one toone odds and so sure one side's going to win one side's going to lose but the side is going to lose is basically only going to lose like a day worth of validating rewards and within two days they're going they're going to get that back so that's how I feel like things are that that's how things will work in

the short term in the long term one kind of model I'm interested in is some kind of model where if a long-term partition happens then perhaps it would in some ways like automatically organize and like figure out sort of recom recombining rules where it would it automatically say you know shards number one through 39 are like are shards that are in sort of the US US hemisphere favoring then shards 40379 are China hemisphere favoring and Shard 80 will be like Russia favoring because nobody likes Russia and the so the and the idea is there that you know just that would to sort of go in the

spirit of uh kind of Juan's idea of systems so working like even if even if the internet breaks in half so that even if you can't talk to anyone you can still talk to like as many people as possible that way the network would still kind of people would still feel confident that you if they're in the US and they have an application on on let's say Shard 35 that it actually is going to be finalized even if it recombines and if they're in China well they can not do anything on sh 35 but they can go and do stuff on CH 63 so like like I think there's a lot of opportunity to experiments and models like that okay so I have a few more questions can I add something yeah just just to mention about BLS because um uh you know it is it is

absolutely secure and uh it was designed by Dan Bonet who's one of the world's most renowned cryptographers and he put it out there in 2003 I think and it's been peer- reviewed and it's it's actually pretty simple cryptography too so it's not something that's very mysterious so there's absolutely no doubt about it simple well not not simple but it's not as compared with some of the stuff that's out there it's not my money that it was Secure but I wouldn't bet the global economy's money that was Secure I mean honestly I mean Dan Bon stuff is uh if if you trust you know ecdsa you should trust BLS right so I mean hold on there BLS does rely on Strictly stronger security assumptions and to be fair pairings are

substantially scarier than otic curve multiplication do you trust it I trust your well for me personally ecdsa has passed the um I I have implemented a test and perings haven't would would you trust BLS would you trust yes or no would you trust BLS um 0.9 something I'm not fully convinced about and this will be a segue for vad to go talk about frequenc you should go and talk to yeah you have you have to go talk to Dan Bonnie I mean I'm not I'm not the man but you know I think most people are within the crypto cryptographic Community except the bls's sound yeah but but is it sound to assume that the threshold will be online in a

oligopolistic like public network setting okay that that that's back to the that's to the consistency availability problem uh I have few more questions um that are hopefully short to answer and mainly directed towards Casper if if they are relevant for you then please answer them as well um what is what do you assume it's it's a bonding time so the time um yeah um for me personally um bonding like as 12 to 2 24 hours um unbonding um it depends anywhere between a week and four months okay yeah it's a trade-off between Capital efficiency and how how often like regular users have to go online to remain security BL your numbers so sorry

was that one hour or two hours to become bonded oh the unbonding to become and a week to four months to unbond okay but you can be uh you can stay bonded for a variable amount of time between right yeah so for me in my current preferred system I have like it's like six-month bonding periods unbonding period I guess or uh both B so the six-month bonding periods like you you you have to place a bond transaction in like period n to be bonded for period n plus 2 and then like you have to serve for all of that and then like if you want if you if you don't Place Another Bond transaction then you're going to be unbonded for the next one and that will also take six months uh that's my preferred I mean I I could probably shorten the unbond time but I but I like

for people to have H when they sign up they're doing time like it's not a happy place to be validator to me right you're putting your deposit down you're going to serve the clients you you've bound yourself to this Duty um you're going to you know be there for at least 6 months uh if you if you sign up again in 6 months you're going to be there for 6 months longer and um you know I don't have I don't want to retain very much flexibility about it at all because when as I do that uh I have less guarantees that I can provide clients about which validators will be online and so if if I by having these discret mandatory sentences that validators have to serve um uh I give clients the guarantee that they will always know 100% of the validator set how much percentage of all Easter do you

assume uh will be sted I want it to be as small as possible as small as possible so so the number 5% 2% 1% less less than 1% 10 to 35% okay interesting so so my feeling is that uh what we need to we need to be is confident that we can recover from all the failure modes uh and willing to pay less for a consensus right I I think right now if you look at how much we're paying like a million ether per month for consensus I think we're I think it's it's outrageous the price uh I think as a community we should we should be trying to spend as little as possible on consensus uh and except that you know if we are willing and a if we pay less then

it might fail more often but if we understand how to recover from failure uh that that's actually a good bargain so I'm cons I'm probably concerned about failure modes that are not so obviously blatant instead that there's like a natural shelling Point around just like hey let's fart hard Fork it but at the at the same time pretty serious so things like sort of a long run you know 50 50% plus like partial soft censorship or whatever so I mean it consensus doesn't cost money in ethereum civil resistance costs money in ethereum um I um well I mean I think we just sort of like naturally think of like like we

think of consens participation as being more sort of like a liquid than a solid like it's already is in terms of dollars rather than in terms of any kind of units so same thing okay what what do you think is will be the ratio between um consensus costs and um attacking attacking the system so in my opinion that is one of the big Promises of of proof stake uh that in proov works the ratio is one to one so if a million dollars are burned per day then attacking costs are basically a million dollars um or less and and proof of stake the promise is that this ratio will become better right it's like basically one to one over R where like R

is like the risk adjusted discount rate for this Capital uh and because the idea is that attackers would lose money on the order of the security deposits but the the cost of consensus will just be on the order of the interest on those deposits yeah I I think the um the big change between proof of work and proof of stake is that in proof of work the cost for the adversary to break the network is bounded right if I'm looking at Bitcoin I know what the hash power is and similarly with ethereum and if I acquire a little less than 50% I can really mess the network up right now the interesting thing about this is that

once this has happened there's nothing you can really do about it if I acquired half the hash rate in bit Bitcoin and I wanted to break it pretty much that's the end of Bitcoin you know the miners could add more hash power I could add more hash power but there's nothing anybody can do to take my hash power away I.E I have bounded cost which of course is a huge security failing this is one of the biggest design flaws in Bitcoin today and not not a design flaw but shortcomings right huge vulnerability you can just look at these systems and say right this is how much hash power there is if I have half of that or sorry equal to what's there already I can I can disrupt the network the difference with proof of stake is potentially we can expel um faulty

validators if you want to call them that right so you can do that in the protocol itself sometimes like validator can be Byzantine and you can expel it but in extremis you can actually say right we're going to Fork the network right and these are the validators that are disrupting the network and we're going to make a decision as a community to Fork the n work and delete these validators from The Ledger right and the adversary who controlled those validators now has to create new validators in in the new network by investing more money so we've changed the equation from one where he has bounded costs right he can destroy the network with bounded costs that's the situation today with Bitcoin and

ethereum we've changed the situation to one where he has potentially unbounded costs and this is a huge advance in security so uh I think people should think about that particular aspect and how we can magnify that and and really leverage that because once you have by the way one of the reasons that Bitcoin has this doctrine of massive hashing power is because otherwi is because the adversary has bounded cost right if you don't have massive hashing power the adversary can just look at it and say well that's not much money I'll invest that and I'll break Bitcoin and that's why you know Bitcoin has this Doctrine if we need huge amounts of hashing power so I have two pages more of questions but I don't want to be self and the time is running out so think it's time to open uh yeah open to the audience for

questions okay I if I make a comment a quick comment and a question on what dominic just said uh I completely disagree with proof of work um I I'm not sure there's even much difference between this in terms of this aspect between proof of stake and proof of work uh in proof of stake just as in proof of work you know how much money is currently bounded so you know exactly how much money you have to put in additionally to compromise the system just like in proof of work just just quickly though the difference is that that money can be taken away from you if you have hashing Hardware I so can so can your mining equipment so just as in not a protocol

right uh yes the protocol can be changed so you can hardfork Bitcoin change the mining uh algorithm and boom but then you're taking away every everyone's mining equipment and not only of of the attacker right yeah so so so the question uh I'm uh one of my interests is in uh how the terminology that people use ends up being their own undoing uh so I have a question regarding uh the use of the word validators that's often uh come up uh in in a lot of the slides and a lot of the presentations it's you know said for for example uh the randomization uh of validators like in

Casper or or the moth paper where validators are said to be randomly assigned to different shards in reality uh my understanding is it's not really validators that are being assigned randomly to different shards but it's stake that's being randomly aside to different shards so my question for you guys is um do you have any sort of anti-il um mechanism there to increase the probability that you're actually shuffling validators and not just shuffling addresses owned by the same person go ahead um so I mean security deposits are this are that anti-il

mechanism and the idea is that like um no adversary should be able to control so many validator slots uh essentially there you know there are the there like in in a simplified model you can imagine that there's only one size of deposit that you're allowed to take and it's the minimum size of the deposit and if you if you have like a deposit that's 20 20 of that then you you need to run 20 nodes uh and like they're all your nodes uh and you know you might be assigned to different shards and stuff but but but the security deposit is the anti-il mechanism and but it's definitely right that we sample uh the stake rather than the owners of the stake right there is there is definit in IND Direction there

but we do require for every node that is sampled that they actually do participate and fill the expectations of the protocol in terms of making bets making blocks Etc is the deposit fix or proportional uh I think it it's it's it's it's an adjusting Target based on the amount of deposits that are being placed um at least in my protocol I don't know the two are kind of well you equivalent I think right it's like one approach is you have a fixed deposit size and if you have 10 times as much then well you have to go go and get 10 validator swats the other approach is that if you have 10 times as much then you get one validator SWAT but the validator swad gets basically assigned to everything 10 times as often and you can show that those are pretty much

mathematically equivalent like I think the main difference is that in with the discrete approach if you have like 1.5 times the Min minimum then you can't really do anything with the remaining 0.5 whereas if you have if you have like a variable slots with a minimum then you can um I I I just going to say from from my own point of view I would um much prefer people have fixed you know the uh the the security deposits are fixed in size and you create a very large number of uh validators so for example if you have a 100 validators what you want to do is create a million validation identities and then if you're randomly selecting some group to do something the variance in the proportion of faulty nodes is

reduced and this drastic Alters the mathematical properties um that you're dealing with in in your protocol so um I'd have a slightly different point of view on that I suppose I to be fair if you if you sort of stretch that out to the limit at Infinity then you Bas that basically means in any kind of charting setup then every validator will have some stake in every Shard and we'll have to download every Shard uh well depending how you organize it yeah yeah um and on the other hand though I think there are there are some benefits for that approach like one of them is that you don't have to think like quite as much about like it does reduce complexity when you have one size and another more subtle one I think is

that if you have a model where each individual validation identity is only making like a very small number of blocks between when it goes up becomes a validator and when it withdraws then like then it makes it harder to do things like retaliating against specific validators you don't like whereas if they have like really long-term reputations then there are like weird theoretic attacks that you can do in in between different validators um isn't there an inherent tension between being reliable um and able to function during a network partition um well let's look at a situation say you're New Zealand and you get partitioned off the network and you

want to have people still in New Zealand able to do transactions that are all local but what happens if the number of validators and consensus nodes um you know if there aren't there that many in New Zealand how do you allow those nodes to keep on going forward putting new blocks on the chain and validate them and then when the partition heals have them not be all invalidated so new New Zealand has I believe around like 0.05% of the world population probably 0.1% of G to 0.2% of GDP or so so if you have 10,000

validators then you can probably expect something like 10 or 20 of them to be in New Zealand now that said obviously for that for that to work on a kind of perard basis then realistically what's going to happen is that New Zealand might end up having like one validator on some shards and zero on other shards so if you want to if if you wants to be able to tolerate partitions that are that tiny then you do need to increase the number of validators if we're going if we kind of change the question to something a bit larger scale like something like I know like Australia then in that case what's going to happen is like basically the block time is going to go way up and you might have like 10minute blocks for a bit and

eventually like the validator reduction process is going to keep running and after one or two Epoch or so then basically like there's going to be a lot more validators they get inducted and you're going to go right back to hopefully normal speed so I just wanted to um say there's a different approach uh which we take so we separate um top level agreement on what the final state is or at least what a digest of the final Global state is that's L one layer two down is a validation layer and it's a global validation layer because we think you can't actually have validation happening on the shards so when we talk about shards what we

really mean is something that's that that keeps a replica of the state data we don't really mean something that validates the transitions to that state data and the reason is that if you allow A Shard to validate its own data right the adversary can attack that Shard and it'll be much easier attacking that Shard than the network as a whole because it's obviously a small partition of it and then once the adversary control controls The Shard he can start you know awarding himself things and exporting his bad data to the other shards who are only validating their own data and consequently have no way of realizing that it's all gone fub bar so um yeah that's a that's something so this Al this same thinking also applies

when you're thinking about how different geographical regions can operate independently okay so it would be possible to create you know a number of networks that are semi-independent right which had their own validation system within them but the question would be if you want to let this network validate its own data and operate independently you know will the other networks trust it and allow that Network to export its data to them right and it might well be there's a threshold you know that if if you have a large enough Network you know large enough networks May be able to trust each other right but there is going to be a threshold and

for the same reason that you can't really just have a Shard validating his own data because the adversary can break A Shard much more easily than you can break the whole network so you need a global validation system which is where a lot of the challenges come in when you want to do scalability right yeah so I want us provide a solution for New Zealand um so you have a blockchain in New Zealand with New Zealand validated that um do whatever you want them to do whether it be running an evm um Shard or not the security is completely determined by the New Zealand validators so no external entity can really attack it unless we're talking about buying the stake or something otherwise they're independent and they

connect to the Global Hub um which keeps track of all the side chains and how many tokens these side chains have so we've developed a block chain to blockchain communication protocol we call IBC where each blockchain is a like client of each other so you the New Zealand blockchain can be a like client of the Global Hub blockchain and vice versa and the Global Hub blockchain acts as a kind of a custodian a virtual custodian and it is the final say of where the tokens are and so uh if I want to move money to my New Zealand account

um I tell the Hub move tokens to New Zealand blockchain and then I can use it there when the network is partitioned The Hub will go down temporarily until it's healed but meanwhile you can use the New Zealand blockchain that works for tokens very easily if we were trying to scale out the general ethereum virtual machine like this globally it it would be very difficult I don't think we can actually solve that doesn't seem like something we can solve okay guys if it's possible we'll get one last question is that does that work okay all right my question is a lot of the stuff you've been talking about has been defenses that are economic defenses where you got to put up money or you have to buy a ton of computer equipment

to defend against stuff what about a scorched Earth attack what if you have a large state level adversary that doesn't want to steal money they have plenty of money they have their own economy and they just want to shut the system down just want to burn it all to the ground what are you doing to protect against that scenario well they can do it they just have to like burn basically grab the mic there yeah the idea is that is that like you know they can be our guest and then we'll just start the network again afterwards yeah and then we'll just like keep on taking their money yeah because they they literally have to buy tokens from from stakeholders uh there are like theoretical attacks where they credibly commit to doing it and then that pushes the price of the tokens down and so they can do it on the cheap

problem is that those attacks rely on this notion that like if a chain breaks the price goes to zero whereas if a chain breaks you can just hard Fork it and restart okay so proven right so it it really so that that that analysis only works in like a onetime game well it only works in a game where you assume that the chain like being 51% attacked is death okay when it's not yeah so yeah so I think this goes back to the difference between you know traditional proof of work networks and proof of stake that you know if if a state level actor purchased enough hashing equipment and had the electricity Supply they could you know switch Bitcoin Bitcoin off anytime they wanted right but if you have a system that's dependent upon holding some

tokens right that are recorded on The Ledger then in extremis the community can get together Fork the network the previously owned the tokens that the the state actor own can be deleted from The Ledger and at this point the state level actor has to purchase tokens in the new chain right and then you know they can disrupt it again but then the thing will Fork again and and so they they have unb cost so actually I think this is one of the most important reasons to move to these kind of architectures if is from a government and they want to 51% attack etherum when it goes to proof of stake contact me I have a lot of ether to sell them I think uh proof of stake can be more antifragile than proof of work um

in some sense of course proof of work chain can hard Fork their mining function right but likewise proof of stake can um hard Fork but but the difference is like we said in proof of work the mining equipment and the infrastructure of like getting cheap electricity and the cooling system and all that is still there and you can still use it so there's actually less collateral in a proof work system thereby we'd say I think we would say that proof of Stak systems are more antifragile than proof of work systems so I just add one there is a way of doing it with proof of work it's called puzzle tows but this is going back quite a while there's a cryptographic primitive called puzzle towers and you can actually create a kind of temporal virtual kill switch over Bitcoin Hardware so you can use you can

introduce this actually to bitcoin and you can give Bitcoin the same property but so when I'm saying proof of work doesn't have this property I mean I mean in the form currently deployed any I think uh something that makes people a little bit uneasy about this talk of like oh we'll just let the thing fail and restart it uh is because like people are kind of uneasy about hard Forks still um and and I and I think that there's like a good reason for that but I also think that uh if you do some careful thinking you'll see that the same recovery mode is what uh the Bitcoin protocol would do if there was uh significant failure so imagine if like a week of blocks was reverted uh because of a long double spend attack like I'm pretty sure the Bitcoin Network would hardfork in order to prevent that

we of blocks from being reverted and hardfork is a terrible terrible name there's so much terminology in this industry that needs to be abandoned literally just put in the bin and just sealed and hard Fork is this it sounds terrible it's called a network up grade for God's sakes right literally right what's the big deal right yeah great that's a great quote to to end on so I think if it's you know we we are we are somewhat over here and uh I have questions myself I'm sure so just to let you all have know for those of you who have questions I also have unanswered questions so uh but nevertheless to give us a little bit of time before we get booted out of the building to chat and socialize I think will end now so let's

thank these speakers our panel so let's