Casper

Transcript

so this talk is basically designed to come out to my first talk which hopefully I mean there were more of you listening to that talk in this talk so I guess we won't have a big problem and basically the the first talk was kind of discussing this the problem space what are the kind of design requirements that we have when we are trying to build a public consensus protocol and Casper is my kind of and you know in collaboration with italic and the field people solution attempted solution to this public consensus problem so this talks to give you kind of an overview of the process that led to the development of Casper Casper's Deline design philosophy the different parts of Casper as a

protocol and then the failure modes like you know what can go wrong given how many faulty nodes so let's let's get started so the first design principle is that it should be suited for public consensus which is basically to say Center for the kind of analysis that I shared in my talk earlier this morning basically Casper should work in a context where a majority you've knows our rationale including to undermine protocol eventually around in large majorities in order to undermine protocol guarantees

so as long as that's profitable so basically what we want to have is coverage of Byzantine faults with disincentives specifically been the default that undermine protocol guarantees so and and the reason we want to cover them with dissing symptoms is because we want an attacker who has a budget to spend to have to budget a lot of money in order to undermine the properties of the consensus protocol so this is like the first most important design goal of kaspar we want to make it expensive for an adversary to bribe a rational majority of nodes under Moe undermine the protocol so and so we want to cover this base of Byzantine faults

with disincentives that's important but not in gold so another another key design of goal is that it should be like client friendly and then the last design goal is that it should be good for users and application developers basically and there and there's - in this two main ways that I that I with what that means to me one of them is that Kasper tells you the state of the finality of transactions so you won't be surprised if a transaction is reverted and you will know when it can't be reverted and then Casper's also a little latency which i think is like really important for user experience I mean as everyone probably agrees when you're out of

website you want to respond right away and distribute application it should be the same way so and we're gonna cover some background knowledge before we really get into the heart of what's new about Casper so first thing is security Casper is a variation on security deposit based proof mistake so it's hard to stress enough how important security deposits are to secure in public because it's protocol especially for state because it's protocols and I'll explain why first I'll mention that this this concept was discovered independently by many people including j-kwon Nick Williamson credits Jake Wanda is working

on his protocol tenement Dominic Williams who he saw on a panel earlier in vitalik and I we all thought of this protocol this idea that we can use security deposits to secure a consensus protocol ideas that people would have to place the security deposit in order to produce blocks and if they do something bad then they would lose their deposit so please stake in general uses digital assets it's not defined in the consensus as anti-civil mechanism or as proof work uses computational resources to find outside of the consensus as T to the mechanism and there are other variations on this kind of proven work thing theme of using outside resources like you have proof the store is proof of bandwidth and all these things could be used conceivably as ante civil mechanism and there have been some people who look at

designs of crypto currencies based on those but basically there's traditionally said to be two fundamental problems of forsake there nothing is a problem and the long-range attack problem so the thing is a problem basically is an traditional proof state court goes like you know pure coin etc next nodes don't have any disincentive from being Byzantine signatures are easy to produce and they don't lose tokens for being Byzantine and so they have an incentive to like sign on both chains and they they cannot they basically have no expenses and so any profit they can make from underlying undermining the Contessa's protocols guarantees is something that they will do in a worst-case analysis because they don't have any disincentives and they'll so basically do it for free the security

deposit solve anything at stake problem by requiring that valide just put something at stake and by making by removing that security deposit when there are demonstrably Byzantine in some way so it basically requires that this proof of them being Byzantine is discovered and published to the blockchain in order to affect their balances in their deposits right because everything that affects the state of Archon has to be published in through box in and so that the state transition function can update their state of the state of their bonds or the state of something in the ledger so basically as long as these evidence transactions aren't censored faults can be punished and now this is kind of a broad almost

philosophical point where in proof of work the consensus in producing changes the consensus is always expensive in an effort to make it prohibitive the expensive for an attacker to produce a longer more a heavier fork so it's it's more expensive always for the network then it should then an attacker should be willing to spend at any time in security deposit groups take consensus should be cheap for everyone except for attackers during an attack and this is kind of a big shift in approach where instead of everyone always incurring more of an expense than attacker might ever incur people don't incur an expense but an attacker will incur a very large expense so this this kind of it's this

approach promises to be much more economically efficient because instead of everyone having to always in current expense only attackers occurred the expense during attack so this is an also very was like an important perspective change and how to secure consents so in purport the disincentive is basically again that you the disincentive is not receiving an incentive for which compensates you for your computational work and security deposit base mistake the disincentives is basically just a forfeiture of their security deposit so then we have a long-range attack problem one attack problem has basically that an adversary controls old keys he's no longer have

coins in them perhaps and well the reason we assume they don't allure normal teasing them because it's cheap for the attacker to buy these keep by these two keys technically to use old keys it's a pretty change that for I have a higher score and this this is kind of fundamental traditional proof mistake and it's fundamental all-purpose takes so long as the thing that people use to authenticate the current state is the Genesis block because the Genesis block is something those by our current assumption produce a long time ago and the people who have is something at stake then no longer have something at stake now and so if you rely on you can't rely on their signatures their signatures effectively mean nothing because they no longer have something at stake and it can't be

punished for making for equivocating for making bad signatures so what we need to do to get around long-range attack problem is to change the authentication model instead of authenticating everything based on your knowledge of the Genesis block you authenticate based on your knowledge of who currently has something at stake and therefore who currently has signatures that you can trust so basically this means that clients have to know who currently has a deposit in order to synchronize to the state and if they're able to stay online often enough then they'll be able to maintain this list so the validators rotate over time the the state of the set of validators today is not to be the

same as the set of validators in two years so if you come online in two years of the only knowing the list of the validators today you're not be able to synchronize to consensus but if you come online regularly enough to watch the validators rotate then you can use the fact that you know who's bonded today to learn who's bonded in the future at every step using the eken assurance that if these people were lying to you they would lose their security deposits so this this kind of is thing called weak subjectivity and basically it's kind of like a single public key for the whole blockchain which you need to authenticate out-of-band before you can synchronize and which kind of changes over time but you can figure out you can watch the change happening if you have the current

public key so you can kind of be man-in-the-middle attacked if you have the wrong key there and you'll let show up in some kind of non-existent economy but and so there's basically some trade-offs here right in kind of proof work you just need to know the Genesis block and you can authenticate the current state whereas in this kind of proof state model you need to be online sufficiently often to have a current picture of the set of Ponta validators so that there is some cost there in terms of what we can provide as a service to notes who are offline very often but there is one main benefit to this approach which is that it's much much much more like client friendly than

proof work or any agenda Genesis block authentication model could ever be because you don't have to download the header change you don't have to compare scores of forks that come from the beginning of time you just you have a piece of currently economically meaningful information which you can use to immediately sync up with the current state and so the level of like kind of friendliness that's possible in this kind of weekly subjective model is much much greater than what's possible in a proof of work or kind of Genesis block authentication model so those are the trade-offs for that design it's it's it's this again this this idea of that you need to know that people are

currently deposit is fundamental to using security deposit based per stick in a way that is economically secure because people who no longer have deposits are willing to sell their keys for free almost straight perhaps on an epsilon is greater than zero so some more background knowledge there's the ghost protocol for proof of work this is a protocol called 3d heaviest observed subtree produced by Samba Samba Linsky in zohar quite some time ago and basically it can reduce the block latency without reducing the security for a purple work chain in proof of work a miner is only rewarded for a block if it is eventually part of

the chain so if there are these things called orphan blocks which miner finds but doesn't get included in the chain and these blocks don't contribute to security of Bitcoin for example but in a theorem we have this kind of implementation of ghost that makes it so that we include orphan blocks and they contribute both to the score of the fork and we compensate the miners for their work so the miners aren't screwed by having their block be orphaned and the spork is secured because we don't lose the work the work still become still as part of like the comparison of the forks so so basically ghost made proof of work lower latency without compromising on security so and basically there but

there there are in theorem we have an implementation of ghost but it's not the full ghost protocol is given by Zohar and somke Lansky and basically we include orphan the headers of orphan blocks into the into block chains and I think should be to their fork but what we don't do is actually have a block tree based rule and basically so and the reason we do this is because it's kind of simpler and we get most of the benefits but if we did have the full of the full implementation we could have even lower at lower latency blocks we also kind of execute transactions for Morphin blocks and selfish mining and and and money of course would be even

less even less attractive so Casper is an adaptation of ghosts to prove thick and we have this similar kind of thing where we can have like a more complex version with like trees and or a simpler version that still has some of the ghost-like properties and this is one of the things that we're still debating between me and Alec about what would be appropriate for the release of Casper basically so certainly incentives will be a function of orphaned information so that much we agree on now what we don't agree on is whether or not we will allow orphaned locks to have the the bets that there including contribute to the that history or whether to

execute transactions for market blocks if we allow these things then we will have it'll be like a little bit more complex from the protocol point of view but it will have we'll be able to have slightly lower latency and basically with more complex versions of Casper that like fully implement this tree choice rule we can go well below the end-to-end Network latency in terms of producing blocks which is good for user experience but it increases the implementation complexity because we actually have to do tree choice as opposed to just blockchain choice so if the old blocks are retained in the innocent in a single chain then they have to you kind of have to wait for at

least half a network latency say well you have to wait for the next validator to produce a block on previous ones so we kind of arguing about whether the complexity of the of bringing the block time below the network latency is worth it additionally this is kind of a neat thing I came up with a way to make this tree choice rule light client friendly so you could imagine that as a light client watching like so network latency blocks you might have a kind of a nightmare really only through mist left you're kidding oh my god do I actually have Theresa oh my god okay so you can't the teachers world and state transition function from our

previous talk Castro chooses availability what we're gonna do consensus by having iterative betting on whether blocks win at a particular height and basically the betting games of different heights are independent and if and the betting games can finalize blocks if you have a whole bunch of finalist blocks in row then you have finalized state so non non finalized blocks sorry final light box aren't reverted for two reasons one of them is that reverting a finalized block would would create a very large amount of evidence of malfeasance which would lead to a very large amount of loss of security deposits so we have an economic assurance that to finalize blocks won't be created because it creates a lot of this evidence which can be used to

punish a lot of them which means that an adversary we have to spend a lot of money to refer to finalized block and the other reason is that clients were there for choice rule will refuse to adopted work that doesn't include a finalized block a finalized block and so this this version of finality via clients strict unwillingness River blocks can lead to consensus failure in the case where there's two finalized blocks shown to G different clients before they see each other's finalized blocks but it provides an ironclad guarantee of finality in the sense that this we know that this block will not be reverted because the client just refuses to do it based on their fortress wall so Casper designed to be sensitive

resistant basically what the way we do this is mean if some nodes are offline we're going to disincentivize if we're going to see that they were censored and punish everyone so it so if you were to censor some some majora it's a minority then the remaining everyone would would lose lose money so that if a large coalition were to cooperate to censor a minority then they would have to do that at their expense so unlike before in traditional mistake it's you don't get a raise for censoring you get you know you lose money your salary goes down so and and then we basically have to go through our failure modes really quickly so history perversion is something that can happen for non finalized blocks in which case clients

will know that the block wasn't finalized because Caspar tells you the state of the finality of the block and so so the that's that's there is like some significant mitigation there preventing finality is kind of a more serious failure mode where a coalition could stop an ally from occurring which prevents them from introducing a new set of validators this is kinda important that you need to introduce you need to finalize a new set of validators before the first set of validators can can rotate because you must know for sure who the validators are when you come online as a client censorship is another is like the most severe failure mode if censorship is successful then evidence

transactions can't get in and people aren't gonna be disincentivized from committing Byzantine behavior because they won't lose their security deposit so while we do have an economic assurance that they're sensitive is expensive if you get sufficiently close to 100% of nodes to get together to censor that disincentive shrinks because the protocol can't tell if there's any censorship at all knows our sensory if some ones are missing it could it could no it could kind of infer that maybe those in the blocking those nodes aren't being included so and moreover the cost of censorship only exists for a finite amount of time because we can't punish people forever if some nodes are offline so there's an there's like a cost that an adversary can pay to censor Network and in there but there are some there

are some ways you can mitigate it one of them is through like cryptographic means you're like time locket ography and sorry I'm really close to done or on the skating transactions basically to make it hard to censor sound transactions as though censoring all of them there's also economic sanctions clients can detect censorship under certain Network assumptions and then they could treat that fork as having a low score and therefore choose another fork which might have a minority of nodes though who aren't censoring or we could just create a hard fork that removes the censoring validators from the set of alligators there's enough community backing behind it then that's like a very strong economic disincentive to attack because if the community is able really to govern the code so well that they can hard work in response to censorship so

while some of these flailing Mo's are pretty bad actually Casper has more complete coverage of faults and in this kind of economic setting than any other consensus protocol out there right now but the devil is in the details there's lots of Parsley's the way that these rules for incentivizing consensus in disincentivizing things have to be specified so the the complete specification isn't available yet as you may have noticed there's still details of the protocol they may be finalized however we are starting to do formal implementation and verification of the protocol specifically we're looking at some of the economics but mostly the convergence properties and that and that concludes my talk sorry for the way