ZKPodcast: Blockchain 101 Cryptoeconomic Primitives and Staking

Transcript

[Music] welcome to zero knowledge a podcast where we explore the latest in blockchain technology and the decentralized web the show is hosted by me Anna and me Fredrik [Music] today we sit down with axel from best to explore some crypt economic principles and the incentive models around staking [Music] hi Anna hello we're sitting with axel

Erickson or oxalate exon as Sweden me wants to say from the company vests gets formerly one protocol and we're gonna dig into some super interesting topics today axel why don't you kick off with just introducing yourself and your background a little bit sure thank you both so much for for having me on like Fredrik mentioned I'm originally from Sweden moved to California to do CS at Stanford four years ago in 2014 I lasted at Stanford for about two and a half years late 2016 I quit to work on etherium essentially full time and in the beginning I was working with my then roommate at the time Zack who became

co-founder at fest on essentially if there are infrastructure related things so there are lots of things that you would want a theorem to be able to do for example you would want it to be able to react to the things happening on chain and you would want to be able to change certain events together everything that happens on a theorem right now needs to be initiated by a transaction that gets sent to the network so we essentially created this generalized alarm clock system there was an aetherium alarm clock at the time where you could schedule transactions to happen based on blocks but we essentially came up with a design where you could schedule transactions to happen based on any condition on the system and then the cool thing about this is that we set this up as a staking protocol where you could send a job to

this the set of machines the machines could take on the job and essentially look at the condition that you sent and then whenever the condition triggered a transaction would be started so the trick here was to punish the machines when they took on a job and they said they were gonna watch this condition but then they didn't do anything when the when the condition triggered cool so that actually leads us a little bit into what we want to talk about today we're gonna be talking about incentives and staking I think to start it might be helpful for us to define a couple terms exactly so this is such a broad area of study that it's helpful to first just talk through the normal terms that we use when we talk about incentive systems and these are like half borrowed from from game theory

so that people that have studied this are going to be pretty familiar and then using those terms there's a pretty simple model that you can use for how to think about incentives in general and we use it quite a lot and it helps clear things up the first sort of thing is that we can think about these systems has essentially games with a bunch of players and the first thing that we want to say about the players is that they're rational and and this of course means that they're acting in their self-interest and the reason we want to make this assumption is that if we assume that the players can be irrational we essentially do saying that they can do whatever they want which means that there's no way to predict basically there's no way to predict and there is no way to reason about the

system because you could have a machine that joins and just does something super weird and there's no way that we can find properties of the system if they can do anything so you'd have to assume something rational in order to create a model at all exactly and for the rational players essentially what we're interested in are the actions that these rational players can take and this seems neat because you know it seems like there may be two or three different things that a machine can choose to do and then we should be able to reason about the system as a whole the problem is that even if we try to look at these actions it's very difficult to know ahead of time what they are so there's this great example from Bitcoin which is called the selfish mining attack where for the longest time it was assumed that

when a miner mined a block it would just broadcast it instantly but it turns out that there was this other action that the machine could do which was simply to withhold the block so you mine a block you wait five or ten seconds before you broadcast it and then of course you get a five to ten second head start on the next block so this was an assumption that was made about Bitcoin that you know the blocks would just be broadcast but there was this hidden action that wasn't known for years it turned into this attack even if we try to nail down the actions in order to think about the system's themselves there other weird things that the machines can do leaving Bitcoin land there's another example for blockchains in general called the verifier so lemma that has almost the same property so the idea is

that let's say you have an aetherium style blockchain and then it becomes super popular and then the blocks you know you have a very high block test limit which means that there's a lot of code that needs to be run inside each block and normally the assumption is that when a node or a minor receives the block it checks through all the transactions to see that the block is valid and that everything is fine but there is this problem when the block is too large it may be in the best interest of a miner to not check through the entire block and essentially just probabilistically guess that it's true and then instantly start mining on the next one let's say that going through a block takes an hour well then you need to do an hour's worth of work before you're able to continue mining so

there's this problem where the verifier or the miner essentially skips the verification so here's another example of this there was an assumption about these block chains that the miners would just always be able to check through the blocks because that was one of the rules but it's fully possible for the miner to choose not to do that and then all of a sudden you've broken higher-level properties of the system like consensus this is like quickly on actions that these rational actors can take and essentially the goal is to create systems that have what you can call good equilibrium so with this assumption that we like to talk about rational actors and we like to talk about their actions the goal when designing most of these systems is to design a system with

essentially a good equilibrium and what I mean about that is very simple essentially a good equilibrium is one that produces some sort of output that's good for the system so if you're designing a consensus protocol this could be you know consensus is achieved and then the other property is essentially that it's very expensive to deviate from this equilibrium and the reason the second property is necessary is that if you simply have tons of equilibrium where it's you know or equilibria where it's very easy to shift between them then essentially the machines can choose between these things and you don't end up having a system that performs one task and a lot of these things are actually like it's not just design the system at a high level - like we're

going to achieve an equilibrium like you're saying you need to achieve maybe a particular one so like in the case of a theorem you mentioned that verifies dilemma there we set a guess box ice limit for a reason that was infinite then obviously you know you could include a hundred megabytes of data and that in itself might be hard to send around but but beyond that like verifying all the transactions in 100 megabytes of data would be so like costly computationally that it would probably not be rational to actually do and you're better off just probabilistically assuming it's correct and you know going about your work for the next block on that so we can't have a too large limit and we can't have a too small limit either so like there needs to be a parameterization that sets

this scene and has the correct cost of deviation and all the things you're mentioning that's exactly right just quickly on essentially having the system converge on to a specific equilibrium another way to frame that is essentially to say that there's a high cost to moving to other equilibriums or moving anywhere else and this is actually very closely related to the security of the system so normally when we talk about the security of the system like this we should essentially just talk about the cost of cheating and this is actually the same as the cost of moving away from from one of these equilibriums we're doing something that you're not supposed to do and you know in in proof-of-work land the security of the system is the cost of cheating and what is the cost of cheating well it's the cost of getting

more than 50% of the hash power and then similarly in proof of stake the cost of the security is the cost of cheating which is the cost of acquiring essentially a large enough voting chair so you know there's cost of buying the tokens and this is why I'm assuming this is why often when you talk about attack vectors you'll say things like yes it could be attacked but the price would be so enormous that it would make no sense this is what you're describing here exactly and you're and you're hitting a key point there as well there is a cost to attacking these systems but it's fully finite it's always possible to you know with an army of people or something like that attack all these systems it's always possible to go around the world with you know some

SWAT team and take down every single Bitcoin auteur theory note it's just that the cost would be like near infinite I mean let's be honest like any major nation state can take down Bitcoin or theorem like any day they want it's it's likely it's really it's likely and this goes back to what we talked about with actions where you know we're looking at an adversary and we assume that you know the actions that are available are like these simple tricks but you know the actions could involve Network level attacks or they could involve you know an army comes and and puts a you know a gun to your face and this this just you know reinforces what we said before that it's so difficult to reason about these systems because the set of actions that are available are

usually a lot larger than what you would assume you're talking about a lot of these sort of assumptions that you make in designing the system and I think we've all heard of like the honest majority assumption which is the same thing is like a 51% attack if there's rights more than first and are dishonest then you know it violates on this majority assumption there are other consensus systems where you assume two-thirds are honest or something like that and others that are super conservative where you assume one-third is honest you know different designs different properties of this system come out of it but there's another key thing that you were talking about which is an assumption on rational actors and there are some evidence to say that humans are

are irrational some and like is there a similar sort of limit system like we assume majority rational or something one way to look at this is to just look at it empirically in the very beginning of Bitcoin for example it was irrational to waste your GPU power or your CPU power on mining a useless currency because it had no value in the beginning so in order for the system to work you needed essentially a few years worth of irrational miners I'm not sure that I would go so far as to say that there's a you know majority rationale or any portion rational assumption but at least in the beginning there is some irrationality needed and we may get into this when we start talking about proof

of stake as well there is this irrationality assumption there as well where token needs to be valuable before be used before it becomes costly to use it to vote on different histories and you could also argue that there's this necessary irrationality there too like bootstrap the currency make it valuable before it can be used for voting but also would you when you talk about like malicious actors like if they're acting maliciously in a system with equilibrium are they irrational it's fully possible that the system is just not designed properly and there is an equilibrium where the miners always tried to cheat because the miners let's assume that they're still rational well there may be equilibriums where they essentially make more money by always cheating but what you're saying there is they're still

actually rationally within that wrongly defined equilibrium exactly it would just mean that the system doesn't produce the outcome that we would want if you had the capacity to to produce a 51% attack on Bitcoin it would be rational to do so so I mean you're irrational but still bad behavior but then if there is this equilibrium you just sort of said that there is a need at least at the beginning for some form of irrationality I'm wondering if there is that connection between like acting maliciously are wrong and being irrational yeah there's an interesting I'll try to find the link to this and put it in the show notes there's a game theory game it's like a little browser-based game JavaScript thing and you click like what you want the actor

to do and it's like a three choice system and basically you build like this bot and you make your choice once and that's like a one-time game and it doesn't seem like there's a bunch of useful information coming out or that but then you start playing these repeated games and you set a strategy instead like I will always pick this or like I will pick this depending on what my opponent picks and there you can simulate an irrational actor by saying I'll pick any choice completely randomly and in in a well-designed system they should be eliminated so eventually they'll lose the game enough times that they are eliminated from the game if they behave irrationally but yet capturing all of this like rational

behavior in a system is incredibly hard I guess a design goal band would be to starve irrational players eventually when designing consensus protocols and other systems but my guess is that that would be difficult to get right yeah okay so we've talked a little bit about these terms and this equilibrium and incentives and I'm curious like how do you then take this and like create a model like what what does a model actually look like right so it turns out that there's this pretty simple model that we can create using these terms to reason about essentially the two major incentive strategies that exist in blockchains and the model is is very straightforward we essentially start by having what we

call a market protocol market protocol it's extremely simple you have a set of buyers you have a set of sellers and there they're buying and selling some sort of digital service so in the case of you know block chains the sellers would be the miners and the buyers would be people that hold private keys and in signed transactions and if you think about it when when you sign a Bitcoin transaction or when you sign in if you're in transaction and you send it away what you're really buying is the service of having your transaction included in the state of that blockchain that's why you're paying the transaction and the cost is the guess exactly its maga Saur whatever sort of fee exists in the blockchain expanding on this model sort of a key thing is always that they're fully sort of open and

permissionless so anyone can plug in as a seller I just run a piece of software on my laptop and all of a sudden I'm a miner the problem then is that we still want the system to produce something good for the users so if anyone can join and when they join they can really you know run any piece of mining software they want they can send any messages to the network how do we make sure that this good equilibrium is still achieved so it turns out that there are really only two major strategies for incentives that exist and the first one is to just play with the amount of money that you pay the machines in the case that they perform correctly so this is in proof-of-work land these are these are the block rewards and what they do is

that you essentially make sure that the machine gets paid it's just a ton of money in the case that it performs correctly such that there is some stream of earnings that it doesn't want to lose out on if it does anything else this would keep it honest and you know that the properties is pretty direct in most proof of work systems if you mind what ends up being the canonical chain you get paid a shit-ton which means that any other strategy like trying to do minority fork or something like that which is essentially just you going out on your own trying to deviate from history it's just costly because you're losing out on that money you wouldn't actually earn any block rewards if you if you did that exactly so that's that sort of strategy number one and it seems fine because we've

essentially just played with the payment and then all of a sudden we've created a cost of cheating which means that we've essentially created some sort of of good equilibrium the the problem is that per definition the users are paying a lot all of a sudden so if you have no inflation this means that the transaction fees probably need to be fairly high to get good security or if you have inflation well that just means everyone is paying so it turns out that instead of just playing with the amount we're paying the Machine the second sort of broad strategy and incentives is it's the underpinnings of staking but it's essentially the idea that we can somehow take something away from the machine when it cheats instead of just relying on what we give to the Machine when it doesn't cheat the sort of broad idea is

that we make it a part of the requirement to be a miner in this system that you also put up this big security deposit we build a system so that we try to detect every case where the Machine cheats which which turns out to be incredibly difficult but if we're able to build it so that we can detect every case we can essentially confiscate or slash this security deposit when the Machine cheats and the key idea there is that we can create the same disincentive to cheating as before but all of a sudden the users don't need to pay a shit-ton every time they buy a unit of service which means that you get the same sort of security but all of a sudden we can massively reduce inflation or the cost per unit of service goes down and if you look at some of the

Casper proposals you will also see that the inflation rate generally is is lowered so this is directly correlated I mean what you described is just the what is it the carrot and the stick but you're I guess do you know you know that expression that's this is carrot and stick and it turns out that the only two weapons we have to play with is the carrot and stick but there's like lots of different sticks and various carrots exactly and turnips exactly and it turns out that it's very difficult to get stick to work but that's essentially it Edie this shouldn't be surprising but it's almost funny that at the end of the day these are the two things that we're still playing with and it's really not crazier than that in current proof of work so like is there actually any sort

of stick I mean other than removing the block reward there there is some stick and this is sort of a an economical stick so is this because they've invested money into their equipment that's not being used like opportunity cost or that's exactly right and and by the way what you said right there is super important there is opportunity cost to using your mining rig towards a certain purpose when there's something else that you could use it for so you see we actually want these puzzles to be as useless as possible because if you know if you could use your your machinery for something else then all of a sudden the cost of attacking goes down because you can sell sort of the output of your machine but essentially there is this very implicit stick which is that if you do spend your hash power on let's

say for a month trying to pull off some attack yes there's some opportunity cost because you may have been able to do something else with it for example mine on another system but there's also the economic depreciation in the machinery so you know what's the resale value of the machinery and that should go down if you've had the machines on which is a tiny stick but you know what we really are relying on is the block towards being high enough so that you would just choose essentially to make a ton of money instead of cheating and we really aren't relying on these like very my new economic things but it's also like part of the reason that you could lower fees in a primitive state system is also that you know you don't need these mining farms anymore you can run a validate or

note on a VPS for three bucks a month or like on your home computer that's exactly right I guess there is still costs to becoming a miner because you need to acquire all the tokens but but generally the costs I guess are are lower the much lower friction to become a miner so that's exactly right so we we've gone through now just this very simple model for how we can think about incentives and what sort of popped out of it where the two underpinnings for proof of work and proof of stake and and you mentioned the carrot and the stick and this is really these really are the underpinnings of the two different strategies and and there is really nothing more to it so we've just talked about these incentive models but what is the act of modeling really like like what is that is it just writing things

on whiteboards is it testing things out like I'm curious when you're creating these models are they only theoretical do they live somewhere I wish that we could use normal game theory to think about these systems you can usually just use game theory when the action space is known if you don't know all the actions you can make you can't really make any conclusions about the system so just just off the bat this means that designing these systems is usually a bit more fuzzy and then beyond just setting up frameworks and shooting out ideas there are these instances where you also need to do live testing so in some of these systems you may have sort of these magic variables these magic numbers that sort of help the system to perform and there's always this question about what

those should be and normally you would want something live to be able to test that and Fredrik mentioned something before which is sort of the block gas limit if that was didn't exist or was set completely differently you may get different properties which is why it's so useful to have a live system where you can just test these things slowly this actually speaks a little bit to an earlier episode we did with Ethan from cosmos about test nets and tried to incentivize actors on test nets with note like where they're using tokens that don't have any value how to get them to act in any way like they would if you could actually act maliciously and earn something that's why I'm curious about like how you would actually model this no it's extremely difficult to to do and to get people to

actually behave like they would in the live setting and the funny thing is that some attacks and this is usually attacks for Bitcoin are actually tried on smaller chains like litecoin and you can sort of see people trying to pull pull these things off just as a testing thing to build up sort of their arsenal for later stuff that's so mean use some competitors watch-chain and be like let's destroy it learn everything we can so we're talking about these incentive structures proof of stake has been mentioned a little bit but we have a whole episode previously with Robert have a Meyer on consensus algorithms and consensus systems in general and sort of

what properties you look for them and if you want a deep dive into that and I recommend listening to that episode but maybe it'll be good to recap a little bit about like what is consensus what are we looking for and then we can dig into a little bit more on like the proof of stay excite sure and that's that's a good way of doing it too just so we get some of the terms out of the way there are a lot of consensus protocol specific terms that they can be confusing so it's it's usually good to just to just walk through them a pretty simple way to think about consensus systems is that you essentially just have a bunch of machines that are sending messages to each other in some way and the goal of this whole system is for them to sort of

agree on some value and then the simplest way to think about that is just that you know they're agreeing on a bit there are variants of this where you know the machines are actually generals that are sending messages back and forth to decide on whether to attack or not but it's essentially the same thing they're deciding on some value and when we're looking at consensus protocols we're essentially interested in three key properties so the first one is whether or not the system is synchronous or asynchronous this really only has to do with whether or not messages arrive within a certain time frame so you can think about your own computer or your own phone as a synchronous system there are separate components that talk to each other but we have some guarantee that like the signals are going to

arrive at some point whereas something like the internet is an asynchronous system there are all these machines that are connected to each other but when you talk to a server or to another machine it's essentially a black box you're sending away a message and you have no idea when or if it's going to come back and if the server is online exactly so so that's the key property and when you send away a message you actually don't know whether the service taking a really long time to respond or whether it's just gone so that's property number one and property number two is available or liveness and it's it's fairly straightforward it's that all these notes or all these machines from the network eventually decide on a value and then the last one is essentially

correctness or safety and the property there is that these machines decide on the same value or rather to honest machines are not going to be convinced that two different values are true so these are sort of the key properties that you have in these systems there are some famous results that people may have heard of that that we could go through very quickly now and the first one just has to do with fault tolerance so some people may have heard the term like Byzantine fault tolerance being thrown around normally this is just called like B of T and the fault tolerance just refers to the portion of machines that can be faulty or trying to cheat before the consensus breaks down so it turns out that in a synchronous network half

of the machines can go offline before things break down and in in an asynchronous network only one-third of the machines can go down I just want to add in that the Byzantine part is important because it means that we can tolerate any type of fault including like maliciously generated faults so there's a lot of consensus algorithms like Raft etc that are fault tolerant to basically machines being offline and that that's the only type of fault they can tolerate but they can tolerate it perfectly well but the raft algorithm can't tolerate machine maliciously or like cooperating with other machines to try to convince the rest of the network that some other value is true just quickly on consensus protocols

continuing on the recap before we can do a bit of a deeper dive into proof of stake there's this other result that that is also pretty famous that people may have heard of which is call the you know the FOP and possibility FOP doesn't stand for anything it's just the name names of the authors but essentially it says that if you have an asynchronous network right so this would be like the internet or like Bitcoin that network can't be both live and safe oh so this is highly problematic so essentially what it says is that you can't have a guarantee that the machines are eventually going to come to a conclusion and they're going to come to the same conclusion which is which is highly problematic and the the the trick with something like Bitcoin is that it's actually not a safe

or a correct system and that there is no guarantee that all the nodes on the network are gonna have the exact same view of what what's happened and then this is why you know you're waiting six blocks or something like that to just have a pretty high guarantee that your view of the network is probably the same as other people's but this is this is the trick that Bitcoin pulls to get around this fop impossibility and normally people say that there was some like big problem in computer science that was solved this isn't entirely true essentially there's just this tiny cheat where you remove the safety of the system and you get probabilistic safety instead probabilistic so the SIS true safety would mean like 100 percent of nodes would decide on the same value

finality is in blockchain terms that so that's actually an interesting point in like a lot of the sort of innovation quote-unquote innovation in consensus algorithms and people invent new ones or variations of consensus algorithms they usually play with these these properties so like there might be a synchronous one that matches all of it might but then you have like all machines need to be online always kind of thing that's like a traditional pbft tender mint pike setup but then you have like honey badger B of T which is asynchronous but then sort of plays with the other factors so you can have probabilistic finality but you can also have probabilistic liveness so you can say it

will come to the correct decision if it comes to a decision Vitalik tweeted once said like a poll asking like what fault tolerance would you accept in your blockchain and it's like one block failure in every thousand blocks one in every million and like never I would never accept any fault faulty block at all and you cannot design a system that would never accept any faulty block and yet like ninety percent voted that option but but so like did yeah so systems you have to like think about this of like what is my fault tolerance actually and you know when will things break so one of the topics that we want to touch on

is proof of stake and I'm curious to see how all of this can be incorporated into proof of stake modeling the general setup is is fairly simple in proof-of-work mining you're essentially voting on blocks with your hash power you can choose different histories to sort of build on and to vote on and the the reason you choose the one that is most likely gonna end up being being right is because there's some cost to voting and proof of stake really follows the same properties you vote with something it happens to be the sort of on chain token that is valuable there's some cost to voting because you can only ideally vote on one of the histories at once and then you sort of end up with the same properties so that's like the

general overview of proof of stake there are some normal straw man arguments that are pulled out fairly early on and the first one is that you know even though you're parking money in one of these systems to be able to vote there's not actually a cost to voting because you know I park a million dollars for a day to be able to vote during that day at the end of the day I still have my million dollars so this counter argument is that if you park a million dollars for a day the cost of doing that vote is not actually a million dollars it's just the opportunity cost on that million dollars so you may have been able to get some sort of returns from the money by doing something else so essentially the cost of voting then for that day is what

you could have done with the money so that doesn't really hold up as an argument and then there are there are these other sort of simpler arguments that are pulled against proof of stake as well like you know it completely has different assumptions because it requires there to be a non token that's valuable that you can lock up and it's true that it requires the spoot strapping event where there's no cost to voting and the system doesn't really work until the tokens are valuable but the truth is that something like Bitcoin that does not start with this like pre allocation or pre sale relies on the same thing there are no rational miners that are going to join the system until the token is valuable and we touched on this briefly when we talked about rationality assumptions you know Bitcoin did rely on probably you know a year

year and a half or of irrational mining people were mining even though there was no value exactly so seemingly no value yeah I mean that's the typical like community bootstrapping problem like if you wanted to start a new boxing today you have these two options of either doing proof of work or proof of stake proof of stake you need to do some sort of ico and build up a bunch of value and hype and do this whole thing but if you wanted to start a proof-of-work chain it's actually completely non-trivial to get this going like how do you get security for this chain when you don't have a community and you don't have value like you actually have to like build up this community of miners and there has to be a significant community of miners to bait to actually build security and we see this in

practice like take security analysis of like from almost anyone on the coin market cap like top ten block chains or like top hundred like vast majority of them are super easily attacked like they just don't have security yeah I don't buy that argument either that like it's hard to improve of stake to build initial security like that's hard in any system like it doesn't matter where it is yeah I'm just I'm thinking about that beginning when you're trying to get people to mine you actually it's not only that you need them to like actively do this they're gonna be spending money which will not I'm imagining would not be matched by any block reward possible at that time depends on a lot of factors

but I mean it's the same thing like either you spend money to buy token in a pre-sale Isao type thing or you spend money to buy hardware to mine a proof-of-work chain that is not secure yet that beginning part of a proof of stake system that actually is super fascinating like when you start a proof of stake system the token would need to have value if it doesn't have value and you just starts taking these like worthless things I guess it's kind of like the test net example no one's gonna act in any way correctly because they don't care exactly the the good news is that it turns out that there are many ways to make something on chain valuable I mean the night the naive solution is just to simply become a market maker and

literally like buy in the self a token out of certain price if you really wanted to but then you completely lack any sort of organic group that that is going to join and provide useful resources later so that's probably not what you want to do it's sort of uncredible in a way a direct solution is to provide some utility so people actually want your token and want to use it now Frederick that's that's crazy yeah so you know this is like the the normal sort of straw man arguments against why proof of state could work there are though actual attacks that are very thorny and problematic that they're also used as arguments against proof of stake but but most of these have been sort of resolved

and the sort of first one that's that's fairly well known is the is the nothing at stake problem and the idea there is simply that what you're doing as a minor is that you're essentially voting on one of a number of possible histories so let's say that there are two histories that you could sort of vote on well in both of those histories or in both of those blockchains you will have your deposit of a million dollars worth of something it's fully possible that either of them becomes canonical so why don't you vote in both and and this is the nothing at stake problem and it's related to this argument that like actually it's it's free to vote in general and this this was a problem but but the solution is you just add this component to the protocol where machines can essentially

tell on each other and sort of rat each other out and say hey I detected a vote at the same block I on you know two different histories and then that becomes one of the conditions that causes you to lose your stake and in theorem there's this concept called an uncle which is a block that was mined at the same height and it can sort of be included and give you some some tiny reward for at least doing some work and then you know these books that you vote on in at least Casper at the same height they're they're called dunkels or dark uncle's which people may have heard so that's the nothing at stake problem another problem that is also thorny but doesn't have a clean solution is the long range attack problem and the idea there is that let's say you go back to

the beginning of the history of the chain and you either are one of the people that has a lot of tokens and therefore a lot of our or you simply you simply go to the person that did have those tokens in the beginning and you and you buy their private key and use it you know you can continue on the canonical chain I just want your private key to be able to act as a voter on block zero and then you essentially create your own history you create your own blockchain use so you sign up as a miner your miner is the only one that believes in this history and you start voting and creating blocks and then you broadcast this entire new blockchain that you've created it to the world and the issue is that for a new node or new miner that joins the network

they essentially have a choice now they can either join the canonical one and you know be with everyone else or they can join your chain the problem is that they have no good way of telling the difference for example in in Bitcoin there is a similar problem where you know theoretically there could be another chain that has a bunch of proof of work done on it and it exists as this alternate chain that you could choose to believe in and this is actually what like the 51% attack is right and the sort of choice rule that exists in Bitcoin is to just follow the chain with the largest proof-of-work what do you do in proof of stake you have these votes they both look legit how do you how do you choose between these two chains so this is a problem and the solution is essentially to use

some sort of outside information to make that choice so this could be you know you go to something's published on Twitter it could be Vitalik and tweets a check point you know or it could be the etherion foundation runs the beacon it really could be anything so you need to use some information the first time you start your node to figure out what history to sort of believe in the argument now is that oh this this breaks the assumption that we had about the system in Bitcoin land all I need to do is to look at the one with the highest amount of proof work on it and then per definition that is the canonical chain where's now you've added this new assumption where I need to like good you know vote Alex Twitter to figure out what aetherium is so this is a problem

but in reality it's it's not a braking problem it's just an assumption change and there's this pretty neat argument which is that hey wait a minute even if you are joining Bitcoin or something as a new node you're also using outside information you're gonna get your your Bitcoin node software from a specific website that you're gonna search for on a search engine so you always use other sort of information to figure out where to start anyway so it's it's not the worst sort of thing in the world I mean there you could have you run into the problem with like phishing sites and do this in aetherium so both gif and parody hard-code and header chains to basically super quickly like sub 10 seconds and

like client so I mean this this is already done it's if not a big deal I think a cool sort of neat solution to think about is and I see a lot of systems popping up like this and what Kasper initially was intended to be but reversed so Kasper on etherium was supposed to be a proof-of-work chain and they used the proof of stake system to like notarize every hundred blocks or something you can flip that on its head and have a proof of stake system where every 100 blocks for every thousand blocks even is sort of notarized by a proof-of-work block and then to have our long range assuming the chain is long enough to have a long range attack then you still

have to produce a bunch of proof of work making it probably you know intangible yeah I think there are some needs like actual technical solutions but practically like you're saying we trusts no developers anyway so might as well hard-coded and you were mentioning miners not validators why were you saying that oh sorry I was just using the terms interchangeably I think miner is is a pretty neat sort of broad term well different systems use different terms for their proof of stake miners so it could be Staker or validator or even Baker and Tasos for some reason so we have we have all of these different terms so I think what we want to talk about is proof of stake I

want to go back to that incentive idea and just very quickly define what are the carrot and sticks in a proof of stake system absolutely so it's not a strict stick it's more like the miner joins with something valuable usually some sort of on chain token that they park and then if they cheat they lose that token so there's the stick in that there's something at loss and then the carrot is not really relied on and proof of state systems as much there is of course still you know a reward for producing good work or like doing what you're supposed to otherwise you wouldn't join in the first place if you're not getting paid for it but the

point is that we're not relying on the carrot to create a cost to cheating we're relying on the stick to create a cost to cheating and is the benefit or the carrot is that way less in proof of steak usually then proof of work so just using the model that we went through it should be able to be less because before there were essentially two components to the carrot one was you know the price of the service being delivered so we need to pay the machine to be there and do something and the other component was this extra bonus that it gets just to to give the the system some security and we can essentially skip this extra bonus but you know what we're really doing is that we're just shifting who pays for the

incentive so in proof of work style systems where we're using these block rewards the users or the token holders are the people that that you know indirectly pay for the incentive and now we've changed the set up a little bit and we've added this huge extra burden essentially for the miners they need to put up you know these massive security deposits they need to go mass go and buy massive amounts of tokens so there's now a cost for them and all the users so we've really shifted just who bears the cost for the incentive from the users to the miners and that's really all that's happened the the the benefits of proof of stake really lie in other properties and other design goals for example now

that we have on chain tokens that that you know create this cost to voting we can slash them remotely whereas in you know proof of work systems there's no way to make your your mining farm you know fail or I guess normally be punished to be punished or like go up in flames or something like that remotely so the difference is that the miners pay for the incentives instead of the users but the benefit comes from other properties that we get by building them this way with you know these attacks and strong and arguments out of the way it's also important to go through sort of the pros a proof of stake there are actually massive benefits to these systems which is which is why there's so much interest in them

and sort of interest in moving away from from proof of work eventually and the goals are fairly straightforward the first one is usually called asymmetric security and cost and the idea there is that in proof of work systems like we've talked about your security is highly related to the amount of money you pay to the miners right so your block awards for this extra bonus is going to essentially define your security whereas in proof of stake you essentially get asymmetric security and cost because the miners put up these massive security deposits the users only need to pay tiny amounts of money to buy units of services but we can cause massive damage to the machines simply because we can slash them and punish them remotely so

that's the asymmetric security property and this is this is actually a very important one there are arguments that you know eventually when the Bitcoin blocked Ward is low enough the transaction fees won't be high enough to incentivize and any amount of you know hash power to join the network which means the security may ultimately falter based on that if you can sort of escape that whole set up with inflation it's a lot neater so that's like the first design goal the second design goal is slightly less obvious but it's essentially that you have lower economies of scale with proof of stake which hopefully leads to less centralization so the the insight there is that there is friction to setting up

a mining company there is friction to like getting a land permit and finding cheap electricity and buying like 10 million dollars worth of Asics and because there's friction to all these steps that are essentially economies of scale if you figure out how to do it you're gonna do it even more and it's very difficult for new people to join and and this this just essentially makes a topology where there's a small number of very large miners ideally in a proof of stake system much cheaper to join there's no difference between running a Raspberry Pi in you know your closet or something like that versus running a you know some other sort of super professional rig somewhere and then all you should have to do is to go to an exchange buy the tokens and

then you should be set to go so so that's another sort of design goal there are things that make counteract this and we'll get into this later when we talk about de passe or delegated proof of State but at least this is a design goal in proof of stake only and the last sort of design goal is to just essentially have lower negative externalities I'm sure a lot of people in the audience are aware of proof-of-work mining consumes a lot of energy essentially you could argue that this is extremely wasteful I've heard arguments both ways where like actually in a proof of stake future but we're locking up billions or hundreds of billions of dollars worth of value in these systems that's also wasteful because you could use all that

money to do something productive in the outside world but but it at least you know beyond comparing these two and trying to figure out which one is is is the biggest culprit at least we empirically see that Bitcoin and other proof work systems consume a lot of electricity and it would be neat to get away from that that's basically it would be either you're gonna waste electricity and energy or you're gonna waste capital exactly and it turns out the capital buys electricity so they may actually be the same thing so that's just quickly on like the design goals of proof of stake as we went through with some of the attacks like long-range attacks and nothing at stake it is tricky to implement these systems and and a lot of these questions are actually still

unsolved we're talking about proofs sake there are some proofs sake systems you know in practice but most of them today or all I'm not entirely sure are what's called DPOs or delia to proof of stake systems and they've gotten a lot of flack but it's also like unclear if there's any other type of system like there's not many proposals that don't involve some sort of delegation so what is delegated proof of stake and you know can we avoid it yeah is it inevitable you're entirely right Frederic in that a lot of these systems are either proof of the stakes systems out of the box but I would even go further and say that if you have a full vm essentially and your blockchain looks like aetherium

and you can write smart contracts they can do you know enough things you can actually turn a normal POS system like aetherium Kaspar or something like that into a delegated proof of state system and this is you know part of what we've been working out on advice you can essentially build the delegation scaffolding into aetherium by building all these smart contracts that determine you know how is a delegate matched up with a machine how do the tokens travel how are they split when the work is complete etc etc so my argument would be that it's probably pretty inevitable that most PS systems become delegated POS systems even if they didn't make that into the protocol originally and it may not be that bad of a thing I'll also

add to here a little bit that you know you mentioned smart contracts and if there's a smart contract platform well I'd argue even if there isn't a smart contract platform delegation is probably inevitable because what we see today with block chains is that most people are perfectly happy giving away their private keys to corporations so like there's no reason to believe that they wouldn't do that in the future as well that's exactly right so the naive way of doing delegation I guess is to set up you know axle mining LLC and then have people like give me money and have some sort of out-of-band contract that determines what happens for the money and then a stake with it that's entirely right it's just that the friction of doing that is a lot higher and if you have like an aetherium style VM then we

can essentially take all those interactions and just put them into into solidity and then all of a sudden it's a lot easier at least a lot of people argue that coinbase is easier than whatever are there wallets there are for aetherium so it may actually be the case that you know the corporate route is the easier one to two-stage we'll see I guess but essentially the change that we make in the in the POS system when we allow delegation is that we allow people that are not running their own machines to essentially allow machines to work with their tokens so you have a choice of a bunch of machines to delegate to if you like one of the machines and you like its turn you can essentially just allow it to act as if it had those tokens at stake on

his own the idea is that you would get a share of the earnings of that machine so the first sort of thing that sort of pops out here is that hey wait a minute the way we incentivized the miner or the machine originally was that we had to put up something at stake and now it's working with other people's money what incentive exists now for it to act correctly and the answer is that we can either use our carrot or our stick we can either rely on the machine just getting a large portion of the earnings of the work so that you know there's some stream of earnings that it doesn't want to lose out on and for the same reasons that we've discussed before it's probably better to just have the Machine stake itself so okay we allowed people to delegate to a machine and then we

concluded that in order for that to work we probably want the machine to stake something of its own but then the question is you know if I have a hundred ether and I get matched up with a Casper miner how much does the Casper miner put up and the answer is that you know it could really be anything but it's arguably riskier for a person to delegate to a machine that has you know one ether at stake or whatever the minimum is versus delegating to a machine that has like a million ether at stake so it turns out that the ratio between the machine stake and the user stake is actually just the risk that the user is taking and and this is this is pretty neat so so that's like the first sort of thing that we notice beyond that there are these crazy new attacks that

come out of delegated proof mistake systems I'll sort of give you one of them what we care about when we look at the miner and its behavior is essentially what it can gain and what it can lose well what it can lose is essentially its own stake and it does it doesn't really get hurt if it loses other people's stake and you could argue that like oh you may have reputation but you know not assuming any of those things it essentially just gets hurt by it whatever it puts up on its own but what can it gain well it turns out that there's this insane attack that's similar to the plot of an old James Bond movie called Goldfinger and in the James Bond movie there's this very evil and rich man called Goldfinger who has a lot

of gold and his plan is to go to Fort Knox in the US you know the movie was made in the 60s or something so that's the time when all the other countries also stored their gold in Fort Knox it's like his plan is to nuke Fort Knox radiating the gold supply of the world making it unusable therefore deflating essentially gold as a currency and then massively increasing the value of his own gold so there is a version of this attack in delegated proof of snake we're essentially you know an evil and rich miner like eath finger or something like that it has a ton of ether and then he he takes a tiny portion of that ether let's say one or five percent or something like that

signs up as a minor and then broadcasts really good terms so you know he goes on a delegation marketplace or something like that which by the way is what we're building and he broadcasts really good terms and says you know I'll give you 80% of the earnings and I put up a lot of money you know my 5% is worth a lot of money so it's pretty secure and then you know eath finger broadcasts his reagan says that you know it's a good setup I ever done electricity and a lot of people delegate to each finger he gets let's say all the other ether in the world delegated to him he becomes Fort Knox and then what can he do well he knew himself exactly he knew himself so he can choose to cheat inside caspere

and they slash B slash along with everyone else's money this destroys the all the other ether in the world and then what's left well it what's left is the you know 95 or 99 percent of ether that each finger chose to just keep in a secret stash so you can effectively deflate the currency itself and and make a ton of money so this is an entirely new attack vector that exists simply because we allowed people to delegate to him and it's it's it's pretty worrying I mean this is an amazing story and case but doesn't delegated proof of stake already have like problems just in that you're delegating to individual node miners actors in eure creating this

centralizing force instead of how it the economies of scale it's or the delegation aspects re centralizes things again delegated proof of stake always struck me as like a popularity contest or something that could be very easily manipulated without even like doing these crazy scenarios just having political actors saying what people want to hear this this is probably true and it is also probably worrying the argument there is like another way to frame that is let's say coinbase ran a steak ER and they broadcast themselves in some neat way would you delegate to them probably so what Frederick mentioned is also entirely

true we have this design goal in proof of steak to have less centralization than before than before by having lower economies of scale and then we've essentially reintroduced those so this is these are like two forces acting against each other you know there's less friction to setting up a minor but for all the delegates that would rather go to the Machine that other people have delegated to and then you know just going back to the gold finger finger attack there are systems that try to partially patch this and they say that okay if a user has delegated to a miner and the miner cheats the miner can't actually slash the user funds so one example of a system like this is Tasos

where there's essentially an amount that the miners can accept from other users where even if the miner cheats it can't slash the funds and then you know if you're above that amount it's called that you're over delegated the issue with introducing that is that yes you you kind of have patched this eath finger attack but all of a sudden there's this new attack where isin liner joined the system I have some number of Tesla's I take 10% of my tessie's and I sign up as a as a Staker or a baker in their system and I take the other 90 present I send them to a new address and delegate to myself all of a sudden I've protected myself from my own potential misconduct and this this is this is

absolutely in the interest of a rational miner because even if you're now protected against like your city going off or something like that because those 90% of funds are from from the system perspective it looks like it's someone else's so they're protected and effectively what it means is that there's less value at stake which lowers the security of the system itself so there are always these trade-offs and other attack vectors that pop up in on that note there is a pro to having delegation as well which is that you increase the amount of stake and therefore increase the amount of security of the network so it's not it's not only a loss scenario like there's an actual website right I'll give you I'll

give you two sides of that upside so from the perspective of the machines if you allow delegation then essentially you're lowering the cost of becoming a miner or or you know becoming a big miner so let's say that you could you could even borrow money from other people to overcome some sort of minimum right this just serves to make it easier to sign up as a machine and in this sort of ideal case there's that I just opened my laptop I run a piece of software I broadcast that I run you know a certain version of the software people believe in me and I just get automatically delegated some funds and I'm a part of the network and then from the perspective of the users the benefit is exactly what you said and a way to frame it is that the cost of joining mining

for users that don't want to run their own machines has also gone down so the cost before was like the cost of figuring out how to run a laptop or a Raspberry Pi or something like that which is like a software it cost essentially and it's also the cost of like keeping the software updated and we've lowered that cost to the cost of sending one transaction to the network I think as as usual when it comes to a lot of this stuff and like I think especially here the Devils in the details and for like like if we take the argument that delegated proof stake is inevitable which I kind of agree with then it's a matter of like how do you delegate what factors to take into your system what like what are the exact

parameterizations of what you're doing if you can increase the friction enough that you like try to counter some of these things so and as an example like the super naive delegate approved stake is that you choose the validator proportional to how much stake they have or have delegated to them so if you have like some super popular guy that has 90% of all stake he gets to vote on 90% of blocks or like he gets to produce 90% of blocks and therefore has like total control of the network so instead of like allowing that you could say well we give everyone equal chance to produce blocks but you get returns proportional to the amount you've staked well now like you're not that much

better off because you have no civil resistance in the system so you can just start up a hundred mining nodes and spread out your load and still like expect to get 90 percent of blocks produced but it's so much harder to do that than it is to just post your you know server address on a forum and get 90 percent so like maybe that small tweak is enough to try to like prevent this enough and like every system that is taking this seriously is trying to introduce some system like this where like Definity has this thing where you can't stake more than X amount and they encourage people to create multiple identities and then they have this huge

like trust network that if I delegate to a friend and then he delegates to someone then I delegate to whatever he delegates to and so they hope to create this or neural net that automatically load balances all the state delegation you know we'll see if it actually works out but people are working on this and and I think yeah like I said devil is in the details what are you actually like what's your exact parametrization of this I think that's important so axel I want to say yeah thanks for joining us on this podcast thank you so much both of you this was this was a lot of fun and to our listeners thanks for listening thanks for listening [Music]