EB105 – Vlad Zamfir: Bringing Ethereum Towards Proof-Of-Stake With Casper

Transcript

this is epicenter Bitcoin episode 105 with guest flood [Music] zamir this episode of epicenter Bitcoin is brought to you by hide.me protect yourself against hackers and Safeguard your identity online with a first class VPN go to hide. me/ epicenter and sign up for a free account today [Music] Bitcoin the show which talks about technology startups and projects driving

decentralization and the global technology cryptocurrency Revolution uh I'm here today with uh Vlad zamir Vlad is probably known to some of you because he's the researcher at ethereum who's been behind the sort of Next Level protocol uh of bringing proof of stake to ethereum because that's been a project for a while for them to switch away from proof of work to proof of stake and and that's exactly the thing flat is working on he's just got back also from London where defc con was taking place I'm sure many of you have heard about it as well it was the very first sort of pure ethereum conference a full week and so yeah thanks so much for joining us today Vlad thanks for having me yeah so how was how was Devcon Devcon

was awesome awesome I was actually kind of shocked at how much like more sophisticated larger uh this was than Devcon zero which was like just over a year ago we've come a long way in one long year yeah I mean I was at def gone zero at least for parts of it and that that wasn't exactly a huge thing and now it's how many people were there um I think 300 around yeah that's that's definitely impressive and it's it's great how how how far the project has gone uh since then yeah it's kind of shocking to look back so when did you get originally involved in ethereum so I got involved

at the Toronto Bitcoin Expo uh back in April of 2014 that's when I really I had learned about ethereum a couple months prior to that but that's when I really got involved it's when I met most of the ethereum team and um sort of started volunteering for them on like a full-time basis or basically as like an obsessive hobby yeah and so was was from the very start your interest especially in consensus and how the network reaches agreement no no actually at first I started working on kind of higher levels of the stack I was working on like distributed applications and infrastructure that distributed applications would need for example uh like file sharing and reputation

systems um and then only after I started kind of learning a lot more was I even able to get involved with the consensus protocol discussions and then I started going down that rabbit hole and then around September last year I realized that like proof of stake is like possible like that we could actually secure blockchain with digital signatures um and then I started you know learning a lot more and going down that rabbit hole which turns out to be kind of much more complex than and involved than I ever would have realized so what was it about consensus and and the possibility of switching to proof for sake that fascinated you so

much well so I mean consensus Protocols are like key to this kind of like decentralization decentralized technology right um and proof of stake specifically is interesting because it is much more economically efficient it can be uh you can have the same level of security at a much lower cost which is appealing to me uh and also there are some aspects of blockchain scaling that are much easier with Pro stake and blockchain scaling is like you know what has been important to me you know before proof stake became important to me right so did you study before did you study computer science before or no my background is in mathematical

statistics okay so I guess that's actually quite related no and especially the way Casper works and and we we'll get to that but you know with the probabilistic models you're using and that sort of economic approach to it sure yeah it's somehow t a little bit tangentially related okay so starting about Casper I mean we've had some people on the show for example we've had like Adam back and Greg Max on the show Once and they asked them about proof of stake and they were like oh this is impossible it doesn't work like it's been proven doesn't work and then there are some problems right that people have talked about uh with proof of stake for a long time and and the two best known about of those are What's called the long range attack and what's called a nothing at stake problem

and so obviously if Casper right you you have to solve those in some way maybe we can we can start by by talking about these problems briefly and and just sort of how you address that sure so actually we kind have solved both problems with the same the same mechanism uh which is uh to use security deposits to to secure the consensus so just for for the people don't know can you also run us through what those problems are and and what those taxs actually look like yeah sure so um the the nothing at stake problem is basically the problem that you have no disincentive from being Byzantine in a traditional proof stake protocol uh because signatures are easy to produce and because you aren't punish

for signing multiple blocks on multiple chains your incentive is to sign off fors when they when they come up uh so the nothing at stake problem is the problem that you don't really lose anything from Behaving Badly right so so so with Bitcoin right if you compare with Bitcoin if there's a forking Bitcoin well you can't mine on both chains because well I mean you you can but you have to split your hashing power but if it's just a signature then what what stops you from signing on two chains at the same time and when you have a fork then the problem I guess would be how do you know they're going to come together again if you know you can have them run at the same time yeah that's right and so to be a little bit more explicit if you split your mining

power due to like uncertainty by which Fork will win in Bitcoin you'll surely lose you know One of Those portions of mining power and so we have a really incent strong incentive to mine mostly if not all on the chain that you believe will be the one that's successful um whereas in proof stake in traditional proof stake you know your incentive is to sign everywhere because doesn't cost you anything and you're going to get Returns on either if there are Returns on any okay great and what about um or so how how is this problem solved so you mentioned security deposit how exactly does that work yeah so the idea is that to produce blocks you have to place a security deposit and

if you behave in a demonstrably Byzantine manner uh then somewh all of your security deposit will be removed from you and so there like will be something at stake I mean the most kind of naive basic thing to say is if you sign blocks on both chains then someone will observe that produce a little thing we call an Evidence transaction which includes includes like proof that you did this and then that would lead to the forfeiture of your security deposit so then there so the idea is that you know there is something at stake and it's this large security deposit and how does that translate into the the long range attack problem or or what exactly is the long range attack problem so the longrange attack problem is a problem that if an adversary somehow gets

control of say a key that held most of the coins at some day time in the past they could use that to create blocks from the past creating like basically a big a big chain that ends up having a higher score than the chain that um is currently the consensus chain so the longrange attack problem has to do with the fact that uh digital signatures are only secure economically secure so long as they have coins behind them uh and then over time keys that used to have coins on them no longer have coins on them and so they're not really economically secure anymore there's no cost you really need to pay to compensate someone for having

that uh and so their longrange attack problem is that people will use old keys to produce chains with higher for higher scores in order to kind of revert history and affect the consensus so so basically it could be like at at the beginning of the chain right there's some keys that hold the deposits of the validators and the bonds and then you know people move away from that and and you know I go to you and say hey you had these keys in the beginning why don't you give them to me they're worthless to you anyway I'll I'll pay you something and I'll do that with a lot of people and all of a sudden I have uh a majority at that stage and then I can start creating a chain from

there um and sort of overtake the real chain and and all of a sudden I have a parallel chain that's actually uh fake but it looks as if it's real yeah and I mean it's not fake it's like it is real and it's just better than the one that exists that everyone is on it just it wasn't the consensus until you just showed it to everyone and then everyone would like switch over to that because it's a better it's a better history how would it be a better history uh in the sense that the fork Choice rule uh gives it a higher score so you know in Bitcoin we have this Fork Choice rule that says like the heavier chain I.E the one with the most proof of work is the one that is that you should choose if you're like client trying to figure out what the consensus is um and

then similarly in proof of Stak traditional proof of stake protocols uh you would have like a longest fork rule can you explain that what what that look like the longest fork rule yeah I mean basically uh you everyone would adopt the fork that is just like longer like has more blocks in it uh and you'd be able to make a longer fork with these keys from the past because um you kind of you have most of the keys right and you can make your fork have more participation than people actually participate in like the traditional in the like main fork okay so because if you have all the keys let's say uh maybe otherwise a problem is like latency

because the keys are across the globe or maybe sometimes uh people don't the participation rate really particip because people don't really always stake right and then that slows it down yeah okay okay and interesting and so how does the security deposit I mean makes sense how IT addresses the the nothing at stake problem right by by punishing people who abuse that and sign on several chains but how does it solve the longrange attack problem sure so basically what happens is that um you will only trust a signature from someone who you know currently has a security deposit and so actually uh the authentication model is somewhat different because instead of

kind of authenticating the current state of history based on the Genesis block uh we we're going to use the people who currently have security deposits in order to uh authenticate the consensus and download whatever changes are required or whatever state is required uh in order to synchronize with the consensus so instead of authentication ending in the Genesis block it ends in a kind of much more timely piece of information which is um the people who have security deposits now now so you have like a list of currently bonded validators and those are who can sign to uh help you synchronize with the

consensus so um that's kind of important because um it prevents longrange attack problems because we don't use that kind of we we never use keys that no longer have deposits on them um for anything ever um and then the way you kind of stay synced up is that uh the next set of validators is signed in by the current set of validators and so you can kind of stay synchronized once you've synchronized once now before you have the list of moded validators you're going to need to get that information out of band uh before you can synchronize with the consensus it kind of serves as like one public key for the entire

consensus and so everyone in the world who wants to synchronize will need to have this list really more more realistically it'll be a hash which you can you know provide Merle proofs to um if you have this like hash or this list then you can synchronize and then if everyone uh and everyone needs to make sure that they have like the canonical consensus hash Or List uh and so basically and I I don't think that this is actually a too terrible uh because you know public key cryptography is hard and people don't like authenticating public keys but it's going to be a lot easier when there's only one that everyone needs to authenticate because then we can use

publishing um and we have lots of reliable means of publishing uh and then and there are like kind of other things like you could for example if you want if someone wants to take a payment from you they don't have an incentive to give you a false hash because um they want to accept payment on the on the authentic chain right so cuz cuz I mean let's say someone did make a long range attack here and and now I have a list uh and and I have a chain too and on that chain I have all the validators I mean and then I could go to you and say hey you know here's the chain I have the validator so so presumably the security you would have is by if you beforehand if you know who

is the true list of validators then when I come to you with my long range chain you would say no these are the wrong validators you know I don't trust this chain uh I only trust chain that has the same set of validates yeah that's right I mean that's that's exactly the idea and so you yeah you just have to stay synced up guys and and and Trust some source to get that correct list of validators yeah um definitely so but if you're staying synced up then there there is no trust there in the sense that you can authenticate all the changes in the set of validators using kind of this econ economic proofs right where you basically can rely on it because if it wasn't true then these

people would lose large amounts of security deposits yeah I mean to be honest this seems like a very reasonable thing to me right because it's I the question I guess will be how do you technical Implement that right how how does a client actually get that list because of course people presumably won't be doing that manually but there will be some mechanism in the client that automatically fetches the list from somewhere and and that's where a lot of it will depend on so that's that's that's a good question right um and this is something that we kind of talk about um one idea for most users is that like when you get your client firstly because you don't you don't actually have an ability to audit the code it would just

kind of come with the most recent list of validators but for a user who's like a power user you'd want to authenticate that yourself out of band and you'd want to go and like look through various places where people are talking about and Publishing these things and make sure that you have the same one that everyone else does um and basic basically uh there the user experience for that is still to be seen part I mean I'm I'm sure there are solutions um that are like super secure where the client kind of just like asks you to find the most recent uh set of validators um but totally from a protocol point of view it's it's it's totally necessary because the set of validators changes over time the set of

people security deposits changes over time and there's no way for you to to kind of authenticate a one at time T you know 100 if you if you only know the set of validators at like t50 because it's entirely different set and you can't rely on the signatures from the first one to figure out the second one so can validators change like all the time or because if you I guess if you were at t50 and you say oh all validators you know they have to bond for at least six months or something right and then well you could tell um to some accuracy if a list is valid at the later stage you know to

the extent that the same validators you know must be included because uh they just can't withdraw it immediately is there a mechanism like that as well yeah totally I mean um that's that's totally right so if so it's totally cool for new validators to come in because your validators are still in there and like you still have all the security you did before the new validators came in um it's when the validators that you know about unbond that you need to start to worry and as a if we have some fixed rule about how long you must be bonded for then for any period longer than that uh there's no guarantee there's no like ironcloud guarantee that the validators

will still be bonded so they might be and they you know probably in practice likely will be because in practice uh you'll if they're profitable they'll stick around and if they're not they eventually won't uh and so some of the validators will be around from one bonding period to the next but if say like you know if say 10% of the the validators you know about are gone maybe that's you know not the worst thing in the world maybe but if 90% of them are gone then that's like quite a disaster for your security and authentication um but basically to keep it simple uh we would requ we should require that like clients know 100% of the validators all the time there are kind of more complicated protocols that

don't have that property where you know you may know less than 100% of the validators but there are perks like more people can Bond at any time and that could be used as defensive used defensively um but B basically like kind of this this kind of gets you an idea of how like uh just like this basic design decision has uh a lot some details that need to be kind of thought carefully through of exactly like how people are allowed to bond and unbond and how clients react to that and how they authenticate based on how many of the validators that they know about are still online how do they find out about changes to the validator set you know these are all questions that we have solutions for uh but we have multiple

solutions for yeah I I mean to be honest so if you just look at it from a sort of a high level the the it seems like a a reasonable and sound solution so I'm curious because a lot of people sort of old school bitcoiners and people who are very you know deeply uh in the space and you're also people who are super smart I mean and and I would say sort of from a research perspective and and aren't so much you know invested in Bitcoin currency uh are very skeptical about proof of stake what do you think that is um so it's pretty easy to understand why you can have an um me uh use resources that are external to the consensus protocol as an anti

civil mechanism right so you like the the assumption is that civil doesn't have as many resources as the honest Network and so uh if you kind of size up people's resources outside the network then and then the majority is probably not civil that's kind of like the Assumption um it's kind of a little bit harder to wrap your mind around how you could use something inside the consensus as an anti-il mechanism to secure the consensus um but I'm actually quite comfortable with this and the I mean one intuition for why you should be comfortable with this is that actually Bitcoin is only economically secure so long as Bitcoin has a price in the first place because the hash power won't be high unless the people are compensated for their expense with something that they can sell to pay for their costs and

so really it's you kind of have this phenomena that if Bitcoin Bitcoin has a price then Bitcoin is secure and if Bitcoin is secure then it can have a price so there's like a bootstrapping that's required and that same mechanism could be used for uh an asset that's inside the consensus being used to hear the consensus because there's an asset in there and still we assume that civil won't have a majority of the wealth I mean you know we might assume we might be just as comfortable assuming that in the protocol than outside of the protocol uh and then because it has a price they're going to be disincentivized from Behaving Badly if they place a security deposit which has a price that

could be red by the protocol yeah that's an interesting analogy that's the first time I heard of that but actually it makes it makes a lot of sense to me and and I guess the challenge here too is is if if you try to explain uh proof of work to sort of normal people quote unquote you know who try to understand how this Bitcoin work I think it's it's actually possible to do that pretty well um you know you can say it's sort of a lottery in a betting game and uh I think it's it works fairly well but how do you do that with Casper with with proof of sake do you try to do that to like explain it to sort of you know people who ask you what are you working on how is ethereum going to be secured when it

switches to your system you know who aren't deeply from uh this industry and this uh ecosystem yeah so I mean surely it's a lot more complicated and it is harder to explain but people usually find it pretty intuitive uh that the system uses security deposits to punish bad actors um that's actually the main thing that distinguishes proof stake security to proof of work security is that um you can make the consensus expensive for adversaries only when they're attacking uh which is very different from the Bitcoin system which makes it expensive for everyone all the time and then Ju Just in case at some point an adversary would want to spend some 50% or more of

that so I think that people on a high level find it easy to understand on a low level when you start to get into all the details it becomes much more complicated at and that's when people who uh have like a a strong preference for Simplicity um can get turned away but um the the advantages of this kind of pro protocol I think are very promising and very worth kind of going through all that and talking about all of the reasons why we have all these design decisions it order and you know uh kind of showing the benefit from the

complexity yeah and and to be quite honest I think Bitcoin is easy or proof of work is reason somewhat easy to explain from a high level too but then once you start getting into the really nitty-gritty and The Game Theory and stuff and Mining pools and and collusion it gets extremely complicated as well so I I think you you sort of have the the same problem there maybe it's even more complicated with something like Casper but uh that's not something where Bitcoin is sort of like trivially simple either yeah so that's actually true Bitcoin is very easy to specify very hard to analyze I'd say that Casper is kind of different it's it's easy to

specify but the analysis is is actually quite quite a lot easier when it comes to uh analysis of like different types of adversarial strategies between validators and that's something that uh I'm sure we'll get into through the course of this podcast yeah so so let's get sorry with that first of all I mean Casper the name comes from from Ghost right uh what was Ghost and and why how is Casper related to that so ghost is an algorithm for proof of work consensus called greedy heaviest observed subt tree that um kind of stretched the definition of blockchain into this like block tree thing in order to provide much more low latency transaction confirmation with the same eventual

consistency guarantees um and basically kind of intuitively the way it works is that instead of having orphan blocks be kind of lost and never contribute to the security of the network and never reward The Miner who M them with Bitcoins orphan blocks could be included as like uncles um and they would contribute to the score of the fork and they would also and and and the miners would also be rewarded for that so that that allows you to do much lower block times without compromising on security uh which is uh good great for user experience and for ethereum as an application platform having low latency is um especially important um so go so Casper is a is the

Friendly Ghost uh it's an adaptation of ghost proof stake uh and so that's that's why it's ghost it's basically designed to to provide low latency uh low latency blocks and to kind of um use orphaned information uh to as part of like the rewards the reward like incentive mechanism let's take a short break to talk about hi. me look when you're choosing a VPN provider you want to make sure that your privacy is protected you know if a government agency tries to force the VPN provider to hand over some of your traffic or B or or browsing information will they be able to do that and is your payment information attached

to the account these are all things that you want to consider when choosing a VPN provider with hi high. me all that's taken care of for starters they're based in Malaysia and Malaysian laws don't require them to keep any logs in fact high. me has no logs of your traffic or browsing uh history so even if a government agency was trying to force them to hand over some information they would be straight out of luck because hi. me has nothing to give them in addition to that they use a third part party payment provider uh which uh doesn't give them any of your payment information so they have they have no way to link an account to like a credit card or a PayPal account so even if you're paying with PayPal or credit card there's no way for high. me to know which account paid for what and of

course if you're paying with Bitcoin then you're completely transparent and so what we suggest is if you're creating an account with high. me if you want that extra level of privacy just make a fake Gmail address and use that to sign in so that way you're completely Anonymous you can give homy a try with their free plan their free plan includes 2 gabt of data at unthrottled band withd you can use any of their free exit noes which are in Amsterdam in Singapore and in Montreal and you can sign up for that at height. me/ epicenter now if you use our URL and if you decide to go premium down the line it's going to get you 35% off and the Premium plan gives you a lot it gives you unlimited data you can

use it as much as you want you can connect up to five devices so your whole household fits on the plan and you can use any of their exit nodes all over the world and they've got like 30 of them and of course you can pay with Bitcoin so give it a try we would like to thank kto me for their support of eps and Bitcoin one of the things that I I understand least well about Casper is that there's a strange thing going on where validators are betting on different chains and then they lose money or gain money depending on if their bet is correct and then somehow this is supposed to sort of lead everybody to bet on the same thing and provide that

sort of confirmation you know that with Bitcoin you the majority might that CH well I guess it doesn't quite carry over the analogy but can you explain how does that betting work and why did you why did you choose that sure so basically um the idea with the betting strategy is that what we're doing is is uh we're incentivizing them to come to consensus um and the way that we're doing that is by having them Place some of their security deposit at stake in a process an iterated process C through which they come to agree on which block at a particular height will have its transactions executed so they bet on blocks uh and they're betting on which

blocks other validators will be betting on so the way they make the most return is if they bet very quickly with very high probability on the blocks that everyone else eventually bets very with very high probability um so they the incentive is to bet in the way that other people will bet in the future and if you don't bet correctly then you're going to make less returns than if you do uh and so everyone's incentive is to quickly quickly Converge on the same block at every height and then once you have consensus on the same blocks at every height then we can have consensus on the state of every application so how does that work do you each validator can

propose blocks or or or they propos to some place and then validat choose which one to bet on with what amounts or anybody can propose blocks yeah so strictly speaking anyone can propose blocks at any height um and then the validators will just like bet on the different blocks that are available at Heights that haven't that they haven't already like bet and converged on um and basically uh but it is worth noting that Casper suggests an order that they should propose their blocks in and that's the order in which um they make the most return if they actually end up producing their blocks if they deviate from that order they end up making less returns and the reason for this is that um we don't want them

to stop certain blocks from winning based on you know maybe they don't like a transaction that's in that block right if uh they they could they could engage in censorship by not allowing any blocks produced by some Coalition who isn't worth who isn't um censoring uh ever win and so while anyone could produce a block at any height and people can bet um at any height their incentive is to do it in an orderly manner in order to increase their profitability okay and then you also have a punishment right so if you if you do bad bets you get punished is that correct yeah so I mean there's there's a

couple of there's a couple of things right one of them is if you bet incorrectly you lose more or like don't gain as much much and that's and that's a punishment uh another thing is that uh we we have this concept of finality right where um if a suff if a threshold of validators bet with extremely high probability on the same block say like 99.99% on on the that that on the same block then uh that block will be it's like finalized and if any of those validators bet for another block at that height or bet with a non-negligible probability after that for any block at that height or even if they propose another block at that height then they'll like lose their entire security deposit okay so first of

all it kind of makes sense to me why uh miners would converge uh but do they have to could it happen also that they don't converge yeah I mean they don't they don't like have to converge they're just incentivized to and if they don't then they're going to be operating at very likely a loss um it always depends on kind of how many transaction fees they're losing so they're making but they're if they if if this is like their security deposit and because they don't converge they only get like this much back then they then the transaction fees need to add up to like a very large amount and the transaction fees really pay the play the role of paying interest on the security deposits and so very likely if you lose like you know a very

large percentage of your security deposit due to non-con convergence you won't be able to make up the rest of it in transaction fees um that said an adversary could potentially bribe Val validators uh in order to incentivize them not to converge uh in which case it might be rational for them not to converge but kind of the goal of the protocol is to make it expensive for an adversary to uh undermine the properties of the consensus so the the other thing I read you wrote Somewhere was that you know with proof of work that the level of security sort of increases linearly so let's say uh a transaction has been you know two blocks deep two confirmations is roughly half as secure as one for for confirmations in is that roughly correct

so um it's important when talking about security to discuss whether you mean Economic Security or Byzantine fault tolerance security so in the security of of confirmations increases exponentially if you're talking about fault tolerance I.E if you assume that like more than 50% of the nodes are correct and that uh every and then then like you know the probability of the of the Byzantine nodes creating a longer for declines exponentially as you get more confirmations but the economic security is only to do with the cost that it took to create those blocks and so the cost of any block is like the same right I mean most 25 Bitcoins um that and then like you know you get 25 Bitcoins for

the first block 50 once you have two 75 once you have three 100 once you have four uh so it's in the economic sense of security that uh is that it increases linearly now in kind of this kind of betting approach validators have the ability to kind of slowly put Place only a little bit of little only suffer a little bit of loss if they're incorrect at first by by not betting with very high probabilities but then once they see that everyone is betting on the same block quickly going to uh bet all all of their deposit so you can have for for a good amount of time super linear growth and the amount of economic clout behind a block being finalized okay and that would also be the incentive for example

for a validator to bet in the first place because if they don't then they lose some or they don't make back as much of their security deposit yeah that's right okay and and uh I suppose that will sort of depend on maybe the risk tolerance or how much knowledge a validator has whether they say we're going to do uh a high probability bet on on you know on this one block or we're going to have sort of a wide distribution of bets across a big range of block because we're not as sure how does the how would the strategies vary there yeah so that's that's that's a that's a great question I mean surely risk preference is one thing that might vary between them

um another one is that like you know Byzantine validators might behave in a way where they're just trying to mislead other people's bets um but generally um you have an incentive to go earlier but you're taking more risk if you GRE earlier and so basically yeah based on their risk preferences they'll kind of have more or less aggressive strategies but in any case their incentive is to converge at least their in protocol con incentive is to converge so so what's that actually going to look like I mean let's say now I'm going to be a validator on Casper uh where do I get this software from that actually makes these bets I mean you know just like a minor has like software that kind

of chooses where to mine the next block uh namely on like the head of the fork U your like validator software wherever you get it from is going to have a betting strategy but this is going to be way more complicated yeah sure because one of the things when I was when I was reading about that and thinking about it that sort of came up with me was that well how is that going to actually turn out right so presumably you're going to be able to do a lot of analysis if you've sophisticated you know and you basically sort of like a hedge fund today tries to understand the stock market and and does gets physicists and uh data analysts uh that do you know models and high

frequency trading and stuff and you know that way often they can reliably do better and it seems here you could end up with something similar right so I would hire 10 people uh put you know become a big validator and and really try to understand you know when can I place the optimal bets uh and presumably I'll be able to do you know way better than someone who just does a little open Z skub repo to have some sort of primitive betting strategy yeah I I don't think that that's at all clear at this point um so firstly like this kind of betting game

is relatively simple right um as a function of what bets you've seen uh it's pretty easy to see what D what block has the highest probability bets from the most validators and you can just kind of so there not there's not that much that you can really learn about the state of the consensus by having more sophisticated algorithms what may help is having uh more reliable faster internet connection to the rest of the validators but uh what we're hoping to do is to show both that if people pursue more profitable strategies then we don't lose any of the consensus properties in

fact the consensus properties just get stronger uh I.E you know finality will happen faster in that case but you also have a centralization probably right not not necessarily so so let's get onto the centralization issue actually so I've mentioned earlier that um validators don't have an incentive to exclude blocks from other validators now what that means is that um even if some validator is kind of slow and lagging everyone still has an incentive to include all of their bets and include all of their blocks and have their blocks win um because everyone is is is uh is punished if they aren't included and or if their blocks don't

win and so actually even if some nodes have performance advantages everyone has to respect every other node if they want to increase their profit ility and so you know centralization is about power dynamics much more than it is about uh Rel like you know whether some node has lower costs or higher returns in another node the important thing is that uh the people who have an advantage can't use it at the expense of everyone else and that they have to get along with everyone else even if those people don't have an advantage uh but you know I actually think that this this betting strategy is relatively simple and that improvements

will not be that dramatic uh and if they if they are then everyone will be able to see how these people have bet and they'll be able to notice that hey there's a way we can change our Pro our programs to bet more efficiently um so I I'm not I'm not as concerned about this uh but I mean I definitely hear you and it is something that could potentially lead to some validators having higher returns than others but in terms of like that the impact of that on the consensus properties and on the decentralization of the thing I think uh that you know it'll actually only improve consensus and that the decentralization won't be affected today's magic word is Ghost G

host head over to let's talk bitcoin.com to sign in enter the magic word and claim your part of the listener reward there was an interesting post by Daniel larer who's the the bitcher guy about about Casper and and one of the criticisms he made of Casper there I thought was very interesting as well was basically uh the point that because you mentioned essentially transaction fees work a little bit like an interest rate so let's say I put up uh $500,000 uh in bond and I run a node now and that node costs me $50,000 a year

you know that $50,000 is independent of the amount of my bond so if somebody else tries to run a node and you know it also cost $50,000 but they only have 70,000 security deposit you know our profitability will be hugely different and there's a strong incentive to have uh you know basically centralization right to have as much of a security positive possible relative to the number of notes a validat as you run do you see that as a problem that you have sort of an economic incentive for centralization there yeah so I it's it's it's again not centralization in the sense that like the majority gets to have special rights that they get to like disrespect minorities over uh but uh certainly uh one of the things that needs to be the

case in for this consensus protocol to be like kind of fair between people with who have different bonds is that the cost of operating a node should be should should be much less than $50,000 or really like very small I mean um you know like even to get like an Amal like a like a web server for a year cost much less than $50,000 it depends obviously on the web server but um I think that will be looking at much much lower cost of operation than that uh so I mean like today you can run an ethereum node on your laptop and if we're running on the same transactions per second um as I mean you can run on Raspberry Pi and we're running at the same rate as we are now with Casper I mean you'll still be able to do it on

your laptop and then we're talking about like a much more negligible kind of cost the thing is though that you would want to monitor it and be kind of diligent about the whether or not you're compromised that's one of the main differences between proof work and proof stake is that if your Note is compromised you could potentially suffer losses in a proof stake type protocol right because you have to have uh basically the private keys that secure your bond they have to be online right so you have to also invest in security there yeah although um much more than not being compromised you need to be sure that your machine cannot publish Byzantine uh Behavior so um you know if if an adversary gets at your private key well that's pretty bad they can try to unbond

you but you have you as long as you still have access to that private key you could potentially um revoke and change that decision but um what you really don't want is for an adversary to get into your machine and cause you to double sign right to try to UNF finalize the finalized in order to have you lose your security deposit right so so so would that be optimal let's say I'm as an adversary I take over your machine and then if I double spend on the other chain and then and then use that transaction immediately to prove that well you double spend or double signed uh then I can steal basically your your bond I mean no you don't steal it I mean the bond gets like destroyed and you make like a small royalty for discovering the malas okay but couldn't I just transfer

the your bond to my account um not exactly I mean it's not necessarily that simple um so the UN there's a large unbonding time where uh basically because you can't just withdraw your bond at any time you need to kind of retire from validating and keep your bond there for a time just in case you're malicious you were you were you were you you double signed right before you withdrew it and the evidence just hasn't come to be yet so there's an unbonding time and during that unbonding time if you still have control of your private key you can revise and say no you know it's not going to go to that attacker or no and or or or maybe you could just like burn it there's lots of things you could do to prevent the attacker to actually get that uh that

money okay interesting and and what about because you mentioned you know it would be cheap to run and no and I guess that's that's sort of way the question turns right is is you know how much secure you need extra infrastructure how important is it to get uh you know super low late thing uh do you need DS protection uh cuz you know potentially then there's a lot of additional infrastructure maybe you need to put in in order to run at least a validator well and securely uh so I guess we don't know yet where that's going to go yeah we certainly we don't know all the details uh but one thing to know while you bring up the Dos is that one

the other validators don't have any incentive at all to Dos you this is kind of very much unlike proofer work where miners kind of Dos each other on a regular basis this is something that like it's known to happen uh because it's like their immediate incentive if some other mining pool has their block orphaned um whereas with in here the the people who would be dossing you would presumably be outside adversaries or maybe people who are being bribed by outside outside adversaries so is the kind of environment you see when you when you think ahead you know now Casp is implemented if is running on Casper do you see a thousand Casper validator or or 100 or I presume it's not 10 that you wouldd like

to see or or or 50,000 and do you think those would be run by hobbyists at home or will those be organizations running them uh I guess like in Bitcoin mining right you have professional companies who invest a lot of money in research where do you think that's going to go so that's a good question I mean to give you an example number we're going to need to see the precise overhead numbers we need to know exactly how much overhead it would cost uh you know for a given number of nodes at a given level of latency so if we knew what latency we wanted and how much overhead it would be for a given number of nodes then we could say kind of okay we you know we can have like 500 nodes we can have a th nodes we can have

10,000 nodes depending so basically the the because all the validators are engaged in beding on all the blocks the O the overhead uh the network overhead increases with the number of validators and so certainly it won't be 50,000 probably won't be a th000 but I'm sure we could do at least 100 so I'd say you know somewhere between 100 and a th000 and as to the level of sophistication of the validators um that's also an interesting question um I think that you will certainly need be more sophisticated than a hobbyist Bitcoin miner which basically just requires you to get a box plug it in the wall to the internet um and so I don't think it'll be like you

know if you want to support the ethereum network you might you should probably like build a Dap or serve files on Swarm or U just like sync up and audit and make sure the validators aren't producing invalid blocks or betting Ro betting and maliciously um so I think it'll be you know some certainly requires a little bit more a little bit more skill than it requires to buy Bitcoins but we have to always remember that mining or validation is a is a service that you're providing to clients it's not meant to be uh that we're that we're like advertising mining or validating to people as like something that they should do as clients or as users this is

something like the S the validators are actually like the largest source of risk to the protocol and the protocol kind of treats them as such um it won't necessarily be uh a walk in the park for the validators all the time um but that's kind of the nature of the thing if we want Economic Security uh then then these validators are really need to be exposed to loss and it'll probably come there'll probably be a time when the experience loss um you know not that miners haven't experienced loss before yeah yeah and what what percentage of miners have to be honest for Casper to work and and are

they different thresholds where it's you know I don't know it's like 30% dishonest miners this can happen 50% that can happen yeah sure so that's a great question uh basically we kind of need to talk about it on a kind of case-by case basis for different types of protocol guarantees so first one that we classically talk about in these context is the reverting history so you can never revert a finalized block no matter how many validators you have um because clients will just not choose a fork that doesn't include that finalized block but you can revert non-f finalized blocks if you just have more validators than were used to not to create those nonf finalized blocks so for example if there are you know 48% of the validators

creating unfinalized blocks then you know 49 50 51% of the validators could revert those blocks it's worth noting that um clients will be made aware of whether or not the blocks that they're receiving as confirmations are being finalized or not and so people won't actually be like caught off guard um with respect to their transaction being reverted because you know it'll be very clear that their block isn't finalized so you know in Bitcoin we have this rule okay don't ship your goods until you get six confirmations and Casper will be you know don't ship until the block is finalized and so if you're worried about like double spends then

you need to be careful that the blocks are finalized before you consider yourself safe and once it's finalized there's no amount of no amount of Byzantine validators that can revert that uh and then another important protocol guarantee is censorship resistance and as I mentioned a couple times the protocol punishes any indication of censorship um by you know do directly disincentivizing the validators who are participating so if like 20% of the validators are being censored then the 80% will uh lose will will be like losing money very likely although it always depends on the volume of transaction fees um and then you know also notably uh if those 20% just go

offline then they the protocol will have to assume that they're being censored and those those 80% will be losing money so so in that scenario what about those 20% are they also losing money oh yeah they're losing money too of course do they lose more money than the 80% that's a great question um it seems like the answer will be yes for a small number of nodes but once a larger and larger number of nodes are offline or potentially censored then they will lose uh less than the majority will right because otherwise that could be like if I'm you know have a majority I might say like okay I'm I'm censoring in minority I mean I'm I'm giving up some money but they're giving up even more money and you know I'm I'm getting I'm going to get them to leave the network

uh and then I get a bigger share of the transaction fees and make more money later would something like that work or are there other ways that a majority can basically cut out minority to sort of increase control and profitability of the network so the only way they can do it is to sunship and the amount of time that they need to wait before they will be pushed offline is something that the protocol defines and basically the way that we'll we'll Define that is to make sure that the co current value of the cost of censorship is almost surely greater than the current value of the increased returns from censorship that you get once those noes are taken offline um so basically like you can look at the cost over time of sensoring and then you can look at the return over

time from having those people left after you know they were dropped out and you can kind of do like this kind of present value calculation to make sure that this is greater than that um and so so like that's kind of so we we do like think about you know is it going to be worth it for them to do the censorship um but also very notably there is no other known public consensus protocol or Public public consensus protocol uh that has this property that is unprofitable to his tensor for example like if 80% of the Bitcoin miners decide to ignore 20% they get a 25% raise immediately in in terms of transaction fees and in two weeks in terms of increase block rewards so like if you think about like two weeks of like you know maybe slightly slower block orward and that's kind of

only if you choose not to lie about the time stamps but anyways if 20 that's not very long and it's like totally worth it 25% raise for minor is a very significant raise um you know the same thing is true of all known proof stake systems um and so Casper is really unique in the regard that there that is costly at all for them to censor um and you know censorship is like sensorship resistance is like one of the most important claim properties of blockchains but so far it's in any like majority coalitions validator position uh sorry interest or min's interest to centor in like every known public consensus protocol okay well let's talk a little bit about Tain because we're

actually we're going to do an episode about Tain very soon and and I I've been thinking a little bit about tenament and learning a bit more about it also because at you know at ARS we work with tenament and the tenament is basically you know a different proof of stake protocol and and it's it's the way tenament works right is that a block is proposed and basically the validators sort of vote on it and you know if if majority of validators have approved it you know that's that's the block um which seems like a very sort of clean and simple mechanism why did you why was it necessary here to have this betting thing instead of something like just one you know just people voting on blocks and and then that being the result sure

so I mean the kind of intuitive simple way to think about it is in tender uh you you kind of pass around votes before you create the Block in Casper you create the block and then pass around votes the reason we call them bets is because it's like literally putting like economic stake as to whether or not the one that you're proposing will become finalized really does and the basically the reason why we kind of do the betting after rather than before the block is created is because we favor availability instead of consistency in the event of network partitions right we don't want to require permission from the large set of validators in order to create a block and the reason for that is that it um well there's there's kind of two reasons but the main reason for that is that uh

it it affects the Coalition economics right if you require a Byzantine quorum to create a block then there is a minority Coalition that can prevent a block from forming and they could use that to say choose which blocks form they can use that to extort the network and kind of by by defining the number of nodes required for a block to be created um you necessarily affect the economics of the protocol and the other reason is that we can provide lower latency blocks because a validator does need to have this back and forth with all the other validators before they provide a client a block right but then you have a block that may not end up being the real block right because it's not finalized and of

course yeah but but but clients are made aware of the state of the finality of their blocks but do you think in terms of a sort of ux perspective do you think that's a benefit because to me it almost seems like it's actually a downside okay so I mean firstly um the ux isn't really immediately the user's experience right it's the it's the application developer who needs to deal with this logic and then and then deal with how they show their user their corresponding like truth of the matter right right so for certain types of transactions um there's not going to be any chance that another transaction comes and uh and has priority over yours so there even if your block doesn't win

at that height your transaction will be included and everything will be okay um so for some applications it won't be a big deal at all but for other applications uh notably like economic applications where you really need to know that it'll never be reverted um your application has the responsibility of telling you you know okay you know yes we got the message and here is what we think will happen and then update that story if things end up changing and now but another another thing to note is that uh because we incentivize the validated to produce blocks in a particular order it will if the validators are successfully seeking profit in protocol you'll you'll have a very high probability of your block

ending up being finalized even well before it's finalized um now if the if the but that of course depends on the validator ability to actually gain the incentives in the consensus protocol presumably if that if they're primarily incentivized by that they will if they if people are also bribing them to affect maybe people's user experience in a negative way then maybe they may maybe they won't um but surely there are many kinds of transactions that um where this won't be a problem and for those and for those transactions or those applications uh it'll be like a uniform positive um now the application developer might not appreciate having to deal with the question of whether uh a transaction has been finalized but um I think that they

would rather have that and low latency than sacrifice lat for the Simplicity of their environment okay so so you think that uh with Casper you're basically you know with tender Min maybe it would take in in in a sort of a larger Network like you hope to have here with 100 distributed noes maybe it would take a I don't know how long it would take a few seconds or well depends and maybe if there's some sort of conflict and stuff maybe it would take longer let's say 10 seconds or 15 seconds so you think it would be better to 5 seconds or how fast is actually Casper going to be well um so velic Target is 4 seconds mine is like one or less um I'm really

hoping to go and like have the latency be as low as tolerable right and the reason I say tolerable is because lower latency always increases overhead right right right so so you say okay it's better to have like know one second or uh where you have you know some probability of it being secured than let's say 3 seconds where you don't know anything and then you have you have a block that that really is final and you know you can completely rely on that yeah I mean and remember that we will get finality eventually anyways um the question of how fast finality will occur is still in the kind of open because it depends on how aggressive validators are uh feeling and how how

aggressive they're willing to be and able to be in finalizing blocks um if the network is really predictable and they can all behave in a really orderly way all the time you could conceivably conceivably finalize blocks uh as fast or almost as fast as tenderman can and still have the low latency likely it'll be that uh tenament finalizes blocks faster than Casper does because um of the kind of gradual way that the validators expose their economic uh kind of stake to the finale of that block um but I you know I think that kind of uh the pure economic nature of the consensus

protocol uh kind of necessitates that kind of thing uh and you know the low latency thing is basically uh a plus from the economic point of view although it may might be the case that validators just get more transaction fees from providing lower latency blocks and so we can maybe weasle it and call call low latency an economic benefit too right can can you say that again I didn't totally understand that one um so I mean presumably and this is kind of like an indirect argument of there will be more transaction fees if uh blocks are low latency because the application experience will be better and so people will be using more daps um and so in a way low latency is an economic aim of the validators yeah know that that makes

sense right but then of course again you go into the lower you go with latency the bigger the advantage is to do you know run validators in high performance data center Etc and you know you're the most pressure dare you create to have or you know more increase overhead and the costs of running a validator yeah that's right and um there is an extent to which that may cause validators to uh you know who can't keep up with that to go offline but in as far as there are validators who say you know don't have great internet connections and super powerful web servers while everyone else does they're validat they will still be included in the consensus

because of the Cooperative kind of Economics involved um so if this change happens it'll have to happen gradually because it'll be costly for um for the validators to leave everyone behind okay great so let's talk about last topic which is a like clients what's that going to look like with Casper sure so Casper is super like client friendly uh because well primarily because of something we mentioned at the start of the conversation which is the fact that we use security deposits to authenticate the state of the consensus so validators having the list of the currently bonded uh so clients having the list of the currently bonded validators will be able to kind of authenticate economic proofs

very easily they won't need to download header chains compare work they can just download like some logs from like the most recent State and you know bounce them off other validators to make get them signed uh or to make sure that they're not Incorrect and then they get quickly have very high economic assurance that um their log is correct because if it wasn't then all these validators would lose security deposits so um security deposit Bas proof stake in general is much more like client friendly than proof work because uh economic proofs are much more concise than Pro of work proofs because economic proofs are just like like hey you know

if 2+ 2 isn't four then I lose $100,000 uh work proofs are like hey 2+ two plus 2 plus two is four I've got you know six blocks on top of it um and then another thing that's notable on this on this on this topic is that um I found a way to do uh sub Network latency block times uh in a like client friendly way so one problem with sub Network latency stuff or like clients is that they have to do the fork Choice rule on a very frequent basis which is not very uh not very like client friendly but uh actually what we can do

is we can calculate the these reorganizations inside the state transition function of a block itself which means that a validator when they publish a block will include okay all the new bets that they learned and then and then which which meant that they need to reexecute some transactions which led to this state which means that you are new transaction receipt is that and so the validator so so client doesn't have to actually do all of that work of reorganizing and doing this kind of crazy Fork tree Choice rule stuff uh and they can still you know have this low latency experience so um you know like Cent friendliness is like a one of the top priorities in Casper's design U

incidentally I I guess I should me measure the so I should just mention and the other design design principles so so like client friendliness is one low latency is one uh and economic efficiency is the main other one and that means that as close as possible we want to create a blockchain that is cheap for everyone except for attackers during an attack we want to have like full coverage of Byzantine faults of disincentives but to not have expenses for for people where possible uh outside of Byzantine faults yeah know I mean I think that's one of the the big attractive things about proof of sake where with with something like Bitcoin and proof of work and that that's going to be a big problem in the future right

with the block reward dropping you know it's going to be less and less investment in the hardware and and that means less security right whereas here you can sort of decouple it I mean okay you still have the security depending on at the the amount that's bonded but you know it's it's sort of not money was it's just money locked up right so you you essentially the real cost of it in a way is only the the the cost of capital there plus of course the cost of operating the validators and stuff but that's right but there's also the cost to the attacker right right and the cost to the attacker is much higher yeah so where are we right now with Casper when

is it going to be life so that's a good question I mean uh I'd say that all the like fundamental research problems have been solved uh that we are arguing about specification details but we're also working on implementation verification and simulation um so basically I I'd say that um optimistically and it'll be done in a year uh in a worse Outlook it could take two years I don't think it'll take more than two years it really depends on um how much work I and others can do on this yes so I guess in that ve what does that look like in terms of funding

because you know if the foundation running out of money uh are you is it going to be continue to be possible for you to work on this and I know also you work with a a guy named Greg who's working on actually implementing it um what's that look like how is um the work on this going to be funded sure so I mean um there's kind of like a broader question which is how ethereum broadly will continue to fund and govern core development even as the foundation kind of becomes a smaller part of the community which is an interesting question one that I spend a lot of time thinking about especially kind of more recently uh and or and I'm hoping that we can have a situation

where we govern and fund ethereum using the ethereum platform and smart contracts uh as far as myself and Greg and hopefully others who will getting on will be getting on board to work on Casper um I'm you know applying for Grants uh augur was generous enough to give me a grant even though I hadn't applied for it just a few weeks ago so thanks a lot to them um and basically yeah I've hired Greg so we you know we it's not it's this kind of research and development isn't free uh we are looking and exploring all all options for funding um but you know I'm not going to give up I'll live with my parents if I have to great well that's that's a dedication that's necessary cool and and so maybe

maybe the last question so you um you mentioned that to me that you me developing this in schola now at the moment I don't think there's a ethereum scholar client so is is it would it be possible to just take Casper that consensus part and integrate it into other clients or would would it have to be implemented in each client you know a new or or do you think everybody's going to switch to Scala or or how is that going to work so certainly everyone wants to implement it themselves and so I think they will um and but Scola uh Scola is compatible with like JavaScript um so certainly at least we can use the

JavaScript implementation uh in with the scolar code as far as the other ones I'm not sure I'm not I don't have much experience as a developer Greg does though and he could he could tell you uh and yeah the reason we're using Scala is because it's compatible with all um with all the JavaScript Java stuff and also it um it is strongly typed functional uh and so we can verify it and simulate it in a much more formal formal manner excellent well uh V thanks so much for coming on that was was really interesting diving into this I think it's a topic a lot of people are interested in and especially if you think of sort of the future of cryptocurrencies I'm sure proof of stake

is going to be very very important so I'm I'm I'm glad we could dive into this yeah I mean uh it's my pleasure thanks a lot for having me uh you know I need to do education in any way I can uh so that people are ready for this kind of thing and so that hopefully we can Inspire more people to work on these problems um and so you know thank you for your part no thanks thanks for coming on flat cheers and yeah thanks so much for listening for joining us so we put out episodes of EP Bitcoin every Monday you can get them of course in every podcast player you get them also on YouTube youtube.com/ PC and um if you're a loyal listener then you know you know what's coming now basically we're still doing this uh sort of bribery competition

where if you leave us an iTunes review and you send us an email show at enter bitcoin.com then we send you a t-shirt uh and yeah you can say bad things or negative things or great things anything is possible uh and yeah so just just do that and we do appreciate that lots of people have done that so far um and yeah of course can always tape the show if you want to so thanks so much for listening and we look forward to being back next [Music] week