 Great. Thank you. So a lot in a lot of the time people ask Ask me to give presentations about things like what is the progress of Casper or what is the progress of sharding or In general what what are future versions of the ethereum protocol going to look like and what are they going to get there? So that question the answer is to get there when they get there, but today what I wanted to talk about is go a bit deeper down and Give a bit of an introduction to some of the kind of thinking process as some of the reasoning that goes into the the ways that we've been Making some more design decisions in things like Casper so far so Just we'll start off going back to the basics, right? So I generally think of blockchain protocols in In general as being a part of this category of a test of a crypto economic protocols Right, and I like I feel like the thing that really fundamentally separates things that are done on Bitcoin things or Bitcoin Ethereum dogecoin things that are done on top of any of the three from anything That happens before basically is this kind of crypto economic element, right? So decentralized systems we've had those for a while and you know even just to fault tolerant consensus We've had that for three years But the thing that's really unique about What's sub-ebal called the blockchain space is that it mixes together these two ingredients, right? It makes us together cryptography and economic incentives so and I'll describe on a blockchains in in those terms I'll be later on right so basically a think of crypto economics as being a kind of methodology for building systems that try to Guarantee certain kinds of information security properties and the two being kinds of building blocks that we have our first of all cryptography And cryptography is about proving properties about messages that happened in the past so If I sign a message it proves that I created it if I In have a message that includes a hash of another message then that proves that that second message came before the first message came After the second message and that when I created the first message I already knew about the second message now economic incentives are Where those incentives are? Defined inside the system and administered by the system are used to Encourage these have participants in a system to work hard to make sure that certain properties continue to hold into the future so We'll take a look at Bitcoin just as a simple example So, you know you can just think about what Bitcoin is for on multiple different levels But you can think about it on a high level and you can say Bitcoin is there to create a peer-to-peer digital currency Or you can think about it on this kind of very low kind of functional level where you say You know what specific things do we want the Bitcoin blockchain to want? You know what specific behaviors do we want it to have so in general and we want to create a chain of blocks and we want those blocks to contain transactions and The Bitcoin blockchain maintains some notion of state So we can think of state in Bitcoin as being how much money everyone has you can think of state in theory MS being How much money everyone has and what is the code of all the smart contracts and what is the state of all the smart contracts? And the transactions affect the state, right? So, you know if the state before said that I have a hundred dollars and I send a transaction Or I have a hundred bitcoins and then I send 70 bitcoins to Christian Then the new state says that I have 30 bitcoins and Christian's balance also increases by 70 roughly Now one smaller functionality that Bitcoin has that we don't really think about but it's also technologically important Is the Bitcoin blockchain maintains a clock, right? So Bitcoin blocks contain time stamps and those time stamps are ideally supposed to roughly reflect reality now Here's some ways of thinking about what a well-performing Bitcoin blockchain looks like first of all We have a property of convergence, right? So ideal total 100% convergence would be is if you have a chain and new blocks can get added to the chain But blocks can never get removed blocks. They never get replaced. You never have reorgs You never have 61% attacks every time a block comes and goes it gets goes on to the chain It stays on the on the chain in that exact same place forever The next block gets out on top of that the next block gets out on top of that validity so we want the the Bitcoin blockchain to be valid and Here's some Definitions of validity so there's lots of lots of definitions of validity One of them is that you know you want to have work to be valid you want blocks to contain the hashes on the previous block You want links to be in the right format Also an important one from the point of view of a currency is that you have this validity predicate So only transactions that satisfy some validity predicate that depends on the transaction and also depends on the current state Should be included in the block So for example if the current state is that I have a hundred bitcoins then I take this transaction sending 70 bitcoins to Christian That transaction is valid sent now if I try and send another transaction after that sending another 70 bitcoins to Christian Because the state changed the second time around much transaction fails Also the clock should be roughly increasing, right? So That's That's one partial condition for kind of the clock or reflecting reality, right? It doesn't cover everything because the clock could potentially increase like 10 times faster than real time But the clock should definitely not be going backwards Here are some more subtle properties that you might not think about but the blockchain also has right? So one of them is data availability. So the chain does not just need to be to Valid it also needs to be available Everyone needs to be able to Download the blockchain when they won't know if if or when they want to right? So, you know if you see a block header and that block header is part is part of the kind of Canonical chain then you should be able to kind of go down the worker tree and download the rest of that block Now theoretically you could imagine a malicious miner or mining cartel Decide to publish a chain of block headers where the blocks that those block header points to are all valid All everything is totally correct, but they hide the data. They don't they don't actually Give Distribute the data in the blocks to anyone else. They just distribute the headers Even though the blockchain is valid even though they're following all the other rules This is still bad and this is still something we want to avoid Availability so this is availability of the protocol with with respect to users of the protocol if You see I have a transaction that trans out and the transaction has a sufficiently high fee Then I should be able to include that transaction in the blockchain Now of course sufficiently high fees might end up getting pretty high as I'm sure some of you are aware But you know you don't want like you don't want a system where you know Even if you pay a hundred dollars or a fuse as you or you know You don't want a system that just like outright discriminates against certain classes of actors so We know you have the blockchain blocks transactions So we kind of know what a well-functioning blockchain looks like right and here are some of the cryptographic tools that it uses proof of work so proof of work allows you base participants in the network to Prove that they have access to a certain amount of computing power and this essentially gets used as part of the Way of assigning identities and the concepts mechanism in some sense Signatures so signatures proof who sent the transaction and hashes and hashes have certain purposes several purposes in Bitcoin Right one of them is that they establish a total ordering of the chain So you know they establish that you have this chain You have blocks and the blocks are in this exact order and know you can't kind of take a block out in the middle and replace it with something else Another function that hashes have is they enable a kind of limited a white client protocol with Merkel proofs, right? So basically if you have a Bitcoin client on a phone and you only wants to check your own transactions You don't have the resources to check the whole thing then you would want to Down you can use this protocol where you only download the block headers only check the proof of work on the block headers and then only Verified the small portion of the blockchain that you actually personally care about and because the blockchain is all kind of linked together Through this hash-based data structure is you can actually do this Incentives so the miner of a block that gets into the chain gets 12 and a half bitcoins Plus and this is something that we think about less But it's also important the miner can kind of extract economic rent from being a kind of a temporary dictator over transaction inclusion So what do I mean by dictator basically if the miner if you send a transaction If the miner of the next block wants it to get into the next block He gets into the next block and if the miner of the next block does not want it to get into the next block Then the miner does not your transaction does not get into the next block Now it's temporary dictator because even if that the first minor doesn't include your transaction some future minor might But even still like this this privilege actually does end up being part of a miners incentive right in the basic now Then create a block in the block does not get into the chain. Then you get nothing And there also is this funny difficulty adjustment property that basically says rewards are marginally long run zero sum So basically no matter what people do the total sum of everyone's Revenue is this going to end up being roughly the same and this is important and what particularly this actually It is one of the main reasons why Bitcoin has selfish mining vulnerabilities So cryptography So we can think about cryptography very generally right so Hashes I mean they have several functions One of the interesting ones is that you can use hashes to prove topological order of messages Right, so if a contains the hash of B then a came after B if a contains the hash of B and B contains the hash of C Then a came after B B came after C and so by transitivity a came after C Also hashes can do other things so they enable these like these data structures that you can kind of crawl through and then verify a very small portions of They can allow in general allow for small pieces of data to kind of stand in for big pieces of data Signatures prove the identity of the sender of a message zero-knowledge proofs Prove arbitrary computable predicates on messages So basically, you know if you have a message and you want to prove some property about it even if that property is it takes a very long time to Verify if you verify it then you can create a proof and other people can verify your proof And this proof is with with you know, the newest protocols He potentially even much faster to verify than the original verification function itself And the other fun part is that you can verify Properties of messages that you know without revealing what those messages are Without even without revealing anything about what those messages are except for the fact that they satisfy the proof So that's one more powerful tool in our toolbox. We also have a bunch of other tools in the toolbox, right? So we have proof of work and proof of work is a kind of cryptographic tool for proving that you have Access to on a certain amount of expected computational effort Good, so if you make a proof of work then on average a certain amount of computational effort was extended and Expended in order to create it erasure codes so We'll talk about data availability later But generally erasure codes one way of thinking about them is they convert 100% data availability requirement into a 50% data availability requirement So for example, let's say I have a one gigabyte of data Then I can use this erasure coding algorithm turn it into two gigabytes And what the algorithm gives you is any one gigabyte out of those two gigabytes Even if it's like a gigabyte made up of tiny different chunks spliced together from all over the file can be used to recover the original data So this actually is something that's going to end up being being useful for us later on a time lock crypto So this is an interesting tool in the toolbox basically it allows you to prove first of all proof stopological order So if B is a time lock is a time lock encrypted value on top of a then B came after a But it also contains a built-in clock, right? So not only did B come after a B came at least some number of seconds after a Homomorphic encryption obfuscation you can convert functions into functions that behave similarly or do the same thing Except in forms that are more privacy preserving so basically kind of black box computation even if the computation itself is being done in the clear so that's Roughly kind of the the kinds of properties that these cryptographic algorithms have right in the nice If you think like a crypto economist Then you don't necessarily even needs to care about the details of how all these properties are implemented You just have to care about kind of what the interface of these functions are so like what what are their inputs? What are the outputs? What do they do? What properties did it have? So it's a and something this part is in some ways. I want a simpler task for them being a Cryptographer actually involved in creating these functions now economics, right? So this is the other half of the toolbox in here One major part of the toolbox is incentives and there's two kinds of incentives, right? So well, there's actually two ways to split incentives into two kinds But so the first way to split it up is you have tokens basically tokens are when you Incentivize actors by kind of assigning them units of a cryptocurrency defined inside of the protocol So for example a Bitcoin protocol you just assign a minor 12.5 bitcoins as a reward for creating a block the Ethereum protocol can assign you 5 you 3 you create a block or If you want to penalize people then you can you can delete coins that they have the second kind of incentive and this is what once again one that's Talked about much less often, but it's also still very important and interesting is privileges So privileges basically means you incentivize actors by giving them decision-making rights Where those decision-making rights can be used to extract rent. So what do I mean now? Remember I think thinking back to Mining right so when you create a block you are a temporary dictator over transaction equations In that block if you want a transaction to be included then you can include it if you want to transaction not to be included You can not include it now Then what happens is that because you have this power other actors in the network can basically have the incentive to bribe you To try and get you to use your power in order to help them right so other people can bribe you to use your block space to include their transaction and this is called a Transaction fee and this is in some ways that intended part of the incentive structure behind how Bitcoin works and behind how Ethereum works and behind how any watching in general works now You can also and you can give people privileges. You can also take privileges away as a penalty So this is the other way of categorizing rewards or a categorizing incentives Rewards and a reward basically means if enough someone does something good Then you can increase actors token balances or give them privileges and you have penalties If an actor does something bad, then you can reduce their balances or this actually written incorrectly I mean do you it should say you should or you can take their future privileges away? So here's some other important concept. So first of all, we often talk about crypto economic security margin So basically a crypto economic security margin is an amount of money where you can prove that Either some protocol worked works. So either some protocol satisfy some guarantee or The guarantee is broken, but some actors in this in this in the system those malicious actors that cause G to fail and End up paying either paying an amount of money X or forgoing some and a revenue equal to X in order to make that make that property not Fail right so you can think about like a crypto economic security margin on you know the protocol sting like the watch and being convergent on Some more finality mechanism being broken on you know, any kind of mechanism that you create having the intended effect So but in general idea basically is that you can measure security in dollars I'm crypto economic proof. So this is a kind of message signed by an actor That's basically you can interpret it as I certify that either some claim is true or I suffer an economic loss of some size Now in some ways you can basically what this what this is It's an object that you can then use that you can like download and check and if you verify that the cryptographic Crypto economic proof is in the right format Then you know that either P is true or somebody lost some amount of money in order to trick you So one example This is if you think about proof of work in the context of a like-minded You can think of a block that gets created as being a crypto economic proof that the ball the block points to something which is in the main or in the main chain in the block itself is part of the main chain Where we get where the predicate P basically is a kind of being part of the chain and the economical loss of size X is Basically the block reward, right now In proof of stake you can imagine crypto economic proofs where Kind of where size X can be a much larger because in proof of work like X is basically Kind of bounded above by the rewards that you can either give miners or take away from miners But in proof of stake you can use deposits and you can make people put large amounts of money at stake And if people make proofs that are false, then you can just delete their money all at once so Then another kind of set of concepts has to do with the security model that you're thinking about so One first of all there are some security models that aren't economic, right? There are some security models that just say we expect two-thirds of the Participants in the network to be nice guys, and you know, this is This is called visiting fault standard visiting fault tolerance There are models that say we expect all actors to be nice guys But maybe some of them might have their servers crash and that's a traditional fault tolerance So there's those kinds of models as well as far as economic models go We have one of the major ones is an uncoordinated choice model and the uncoordinated choice model assumes that all Participants in the protocol do not coordinate with each other. They have separate incentives and they're all smaller than some given size So they're all small smaller than some given percentage of the network So to give one simple example the Bitcoin network is secure in an honest majority model with them If the attacker has less than 50% But it's only secure in an uncoordinated choice model if an attacker has less than 25% Because 25% is the bound for selfish mining Coordinated choice model. So that's a model that basically assumes that all actions in a protocol are controlled by the same agent or controlled by the same coalition Bribing attacker model. So this is a model where you have an uncoordinated choice assumption But it also assumes that there is some attacker or the bribing attacker And the bribing attacker is capable of making payments to actors conditional on those actors taking certain actions Here the bribing attacker model has two parameters The first parameter is budget which is how much is the attacker willing to pay it in order to carry out an attack and the second Parameter is cost which is if the attacker does carry out the attack and it succeeds then how much does the attacker actually end up paying? Now to illustrate all of these we can think about what just one simple example shelling coin And so shelling coin protocol is this kind of simple Kind of naive way of trying to provide the true answer to some question. So for example who won the election, right? And Here's the algorithm step one. Let's say you're trying to choose between a or B, right? So everyone votes a or B step two the majority answer is taken to be the correct one Step three everyone who voted the same answer as the majority gets a reward and everyone who voted the same answer as the minority So that's the algorithm right now you in an honest in an honest majority model is this algorithm good This is a question just to check how people are following along In an honest majority algorithm, does this work? Yeah, okay, and this work basically because you know the majority You know we expect an honest majority to vote honestly right now in an uncoordinated choice model what happens? so Here's where it becomes interesting right in an uncoordinated choice model it also works because You have the incentive to vote the truth And the reason why you have the incentive to vote the truth is because everyone else is going to vote the truth And you only get a reward of P if you agree with this majority now Then you might ask well Why is everyone else going to vote the truth and the answer is because they're thinking in the exact same way that you are So it's this kind of recursive equilibrium, right? But in in an uncoordinated choice model it works now It's not the only equilibrium, but it is an equilibrium and if the system isn't this equilibrium then It's an equilibrium and it can stay in this equilibrium. So Now we let's try and think about about this in actually before even get to this We can think about this in a coordinated choice model. So in a coordinated choice model, you know, it doesn't basically does this work, right? Any ideas So the answer actually is basically that the incentive is kind of neutral, right? So the reason basically is that if you imagine n participants if they all vote for a they get a reward of n times p if they All vote for b they get a reward of n times p. So now you Base now what you could say is that you could say that you know if the participants in this network care about it's Kind of people trusting it in the long term then you could imagine that you know There's a bit they get a bit higher reward for a if a wins if a is the correct answer than a few wins And this is a kind of public good that's spread across all the participants So you could imagine that if you start try to include these kind of good will factors then in the coordinated choice model It does have some security Now let's look at the bribing attacker model. So this is the kind of infamous people steps on attack that Andrew Miller came up with about two years ago Basically a bribing attacker can corrupt the shelling coin game with a budget of people steps along and the cost of zero Now what do we mean by this right? So here is the default game, right? So the default game basically is if you vote zero and others would zero you get the reward if you vote one others But one you get the reward, but if you disagree with the majority you get nothing So here you have many equilibria, but everyone telling the truth is one of those equilibria Now let's look at what the bribing attacker does the bride of attacker as This columns this spot this extra reward here into the matrix Basically what the attacker does is he is he says and you know, this could be a crypto economically in force This could be a smart contract bribe basically the attacker says if To anyone who votes one if let's say zero was the correct answer the attacker wants to trick them into voting for one If to anyone who votes one if the majority's vote zero then I will compensate you people steps along You know if you vote one and the majority also votes one then I'm gonna pay nothing But if you go with me and you vote for one and you end up losing then we'll compensate you and I'm gonna add a bit extra So now let's say you are a participant in this model and you decide you're wondering what are you're gonna do? Now there's only one equilibrium Because no matter what your beliefs are about how others are gonna vote you voting one has a higher reward than you voting zero And so everyone votes one and so the attacker actually ends up in the bottom right square It's only attacker actually ends up paying nothing right So that's what I mean by a budget of people steps along versus of cost of zero You have to be willing to pay people steps along but you end up not paying anything So that's just a bit of an example of how kind of the three models can give radically difference of responses to many kinds of games Proof of work turns out proof of work has a lot of the same properties that cell and coin does right Basically because proof of work is also a game where you get more money if you're a part of the majority And so you can do people steps along attacks on it In the same behavior on an uncoordinated choice models and same behavior in coordinated choice models Now let's move on a bit and what it faults, right? So Faults basically are you know situation where you can think of faults at several different levels So one level where you can think about faults is you can think about faults of the protocol All right, so you can think about a protocol that does not satisfy some of its desired properties So for example, you could imagine you have the you know a blockchain then that instead of the at some point Instead you know instead of the blockchain adding another block the blockchain kind of doubles back three blocks and makes enough And it kind of forks off and those three blocks that were originally there just kind of ends up disappearing off Off into nothing or getting included as uncles or whatever else, right? So that's a deviation from optimal behavior because you know a transaction It looks like the chain was going this way, but like actually it turned around one and once another way Faults of individual actors in the protocol So individual actors might you know the servers might crash they might decide to be malicious They might decide to do various things they might get bribes to do various things and false of the network So networks might have latency or networks might Just what can not let certain messages pass through Or potentially might get a you know in a kind of worldwide partition I know you could imagine if World War three starts and a bunch of undersea cables get to get cut and you know the US and Eurasia Split off the two different internets. That's also a network fault categorization of faults right so one oh so Here's one way where we can categorize faults at least faults of Individual faults and faults on the network So we can think of a protocol as being a function that describes what a node is supposed to do right So we can just think of a protocol as a function that That takes as inputs the set of messages. You've already seen then some auxiliary data and Auxiliary data might include the time it might include who actually won the election It might include you know any other data that you're supposed to have So it's a function that takes a set of messages. You already saw the In plus one you saw them other than the auxiliary data and it and outputs either nothing or some message that you're supposed to send so Here's how we can categorize faults one one thing we can say is One kind of fault is invalidity right so in volatility basically means a node sends a message where that message is not the result of executing the protocol for any Subset of the messages that the node actually saw so that basically the node is just like not running the program at all They'll just you know basically in this case the node has to have kind of stuck a wrench into the program and kind of You know jiggle the transistors around or dump the software equivalent of that so For kind of any reasonable ox or for any subset of the messages that the node actually saw The next one is a qualification now we can think of a qualification as Being kind of like your program forking right so basically you imagine you saw some message Then you faithfully so you saw a message M1 then you faithfully follow the protocol as if you saw message M1 Then you pretend to unsee message M1 and then you see message M2 And then you send a message as if you were faithful to follow the protocol as if you saw a message M2 But as if you never saw message M1 right so basically it's like when you know the kind of graph of What you saw it doesn't look like a straight line it looks like you better saw some things But then you forgot them So this is called a publication Ignoring and delaying inputs, so this is basically consistently pretending that some message that actually arrived at some time T1 did not arrive until some later time T2 and possibly you can just ignore messages completely so that's T2 equals infinity Not sending or delaying outputs So this is when you're supposed to send a message but either send it later or T2 equals infinity you never send it at all Using false values of ox. So for example if Trump won the election, but you decide you For either you really don't like Trump or you want to screw around with the system You proclaim in the Schelling coin game that Hillary won the election Special case remember what part of ox is time, right? So sending messages too early is a special case of this and another one is that now those are all individual faults We also have network faults, which basically is a latency or dropping messages um So fault assignment right so one thing that we can do is if we have a measurable protocol fault So there's some protocol faults that you can't measure right but so But you know there's other protocol faults where you have clear cryptographic evidence that says you know a fault happen So one example is that if you have a proof-of-work blockchain And you see two blocks that were built on top of the same parent that is a clear measurable and provable Network fault right now given that kind of fault and given a fault that we can unambiguous we identify We can often inside the protocol Nearrow down why the fault took place at least the one within one of several scenarios So here's just one example to go through a blockchain board, right? So you have you know, you have your network the miners and it's happily trudging along In Then you have block a then uh-oh on top of what a you have Watch the ANSI and on top of what see you have walk D and presumably on top of walk D Tra la la la happy blockchain again, but you still have this fault in the middle. So Whose fault is it? We have five cases Case one is be ignored C&D, right? So B saw C&D's blocks or B saw C's block, but B said screw you. I'm just gonna build on top of a This could be because B just really doesn't like C or this could be part of a selfish planning attack Or this could be and it'll because B's computer is corrupted. What's what's the different reasons? but the point is it is and It is a fault of pretending not to receive messages case to see ignored B, right? So it's entirely possible that be made a block first then see saw that block see could have built on top of it But see instead said I screw you. I'm just gonna build on top of a and then D Had a binary trace between B and C and D just happened to pick C Case three C did not sense to be right. So C created a block, but C said, you know what? I'm not gonna send this block to these other miners. I'm just gonna keep the block and maybe I'm gonna send it to D Because he's my buddy in So that's also a fault Case four B did not send to C, right? So maybe B created a block, but these are like, I'm not gonna send that block I'm gonna try and selfish mine or whatever, but B ended up not sending the block C ended up creating a block creating their own block and Dn just built on top of C in case five network faults, right? So they could have just created those blocks at close to the same time and because of network latency They just ended up creating them on top of the same parent So this is in a fairly exhaustive categorization of you know, what could have caused this to happen? Now here's one thing that you might notice here You might notice that the fault categorization here is symmetrical, right? So for every story that blames B, you have a story that blames C now What is this? What does this and does this imply, right? So Well, here we're gonna start working at some of the kind of principles of crypto economic penalty assignment All right, so basically if you have a fault and that falls ill Then the next question is who can you blame for the fault? If you can blame one party unambiguously if you can unambiguously prove that one specific party is faulty Then you should kick them and kick them again Kick them again and kick them again until until you've kicked their entire deposit down Right, you just try and punish them as hard as possible and the reason is well Why not the more you can punish them the higher your crypto economic security margins? Now let's say you can't choose let's say, you know it down to one of two people who is guilty But you don't know which one now what that you could do is you could just you could just kick both of them, right? You could just kick both kick both kick both and leave both who is their deposits Now this still has a high crypto economic security margin But it has a it has a flaw right basically because in this kind of if in a protocol that works this way There's a risk that innocent validators are going to end up having to just get in completely destroyed Because they just ended up kind of falling in with the wrong crowd in some crypto economic sense So, you know, you know, even if it's not your fault you could get slashed, right now. This is bad So we're now we still wants to punish both participants We still want to punish people who are faulty, but there's a balance, right? There we are you have to kind of trade off between having more crypto economic security margin and having a protocol that has a Larger briefing opportunities so protocol that has a larger opportunities for people like actors to maliciously cause other actors to lose money So there's a trade-off now third principle pay for performance So the total reward the total rewards paid to all actors should be an increasing function of some metric of protocol quality The better the protocol does the more you should pay people So here is how you might assign penalties now What now you might notice that in the five stories we gave a is exonerated, right? None of the five stories blamed a D is exonerated None of the five stories blames D but B and C were each blamed equally right the blame was cement the fall cat the False possibilities were symmetrical for every story where B is at false There is a corresponding story where C is at fault and so by the principles of crypto economic and fault assignment You would actually want to penalize B and C equally You'll notice this is actually a very substantial departure from the holy book of Satoshi, right? In the holy book of Satoshi C gets a full reward because C is part of the chain and B does not get a reward because B is not part of the chain and that's it but we're seeing that bit in According to the crypto economic principle penalty assignment, which are which are better than the holy book of Satoshi we can create a set of Basically, they say that we should do this different thing and if we do this different thing then First of all, we have more incentive we have more incentive compatibility. We have more ability We have stronger performance under the coordinated choice model and as a side effect. This actually fixes selfish mind so Now why is this better under the coordinated choice model, right any ideas? I'll I'll give you a hint Property three pay for performance basically is like an exact synonym of the working while under the coordinated choice model Do people understand why that's the case? Okay, so basically a In the coordinated choice model you assume that decisions are made by a coalition Which is fully you're colluding with it with each other, right and the coalition Care is about its total revenues. You know over here. I basically say total revenues should be an increasing function of protocol quality So in a coordinated choice model basically the coalition should be in is going to be incentivized to make to make protocol quality Be as so be as high as possible. So have as few protocol faults as possible, right? So that's Now basically the idea Benefits if we know someone is faulty they'll be punished Innocence may be punished too, but we can kind of analyze griefing factors We can analyze griefing bounds and we can try and make sure this isn't too big of a problem And salvage mining issues are easier to resolve So we can look at proof of stake in this model, right? So proof of stake you have a consensus algorithm We are in that consensus algorithm instead of using proof of work uses signatures that are signed by bonded validators Bonded validators basically means you are an actor in this network and as part of the state You have a deposit where the deposit is worth some amount of money and but you cannot take the deposit out right you cannot take the deposit out at least without some kind of a long-time delay and You can the protocol allows bonded validators to do things But if the bonded validators do something where they can be unambiguous we attributed to be faulty Then the protocol will slash your deposit down, right? It's going to kick your deposit to death and so Properties that we want to have safety so we want to now here We cannot unlike a blockchain that unlike a proof of work chain that only has convergence properties Basically or the only has kind of probabilistic convergence and kind of linear economic security margin Here we can have a notion of kind of hard finality where you can come up You can come up with a protocol where after enough validators sign enough of the right kinds of messages You get to a situation where a block is finalized and can't get un-finalized. It just can't And we want to have a property of liveness. So basically liveness kind of as in proof of work blocks keep getting produced and blocks keep getting finalized One of the reasons why the crypto economic security margin a proof of work is very high is because right a proof of stake Is very high is because in a proof of work model the Because identities are anonymous because minors are anonymous The only way that we have to incentivize minors is by either giving them rewards or giving them privileges or taking away the rewards and privileges Right. So basically if you want to have a crypto economic security margin of size X you'd better be prepared to pay people X In proof of stake because we have penalties we can actually go much higher than that, right? So, you know your people are generally familiar with the notion that you can stick money into a deposit You can earn interest on the deposit you can take the money out but Potentially the amount that you have to pay the mechanism has to pay people is only the value of the interest and The by the way the interest could potentially be paid entirely in privileges, right? The interest could potentially be paid entirely in just the ability to go up transaction fees but so the security mark The amount that you have to pay is only the interest but the crypto economic security margin is the principle and the principle is much higher Right. So like that's another the basic principle here No pun intended so Here are some properties that we want proof of stake algorithms to happen, right? So this actually kind of follows along with traditional visiting fault tolerance consensus theory in some ways But there are some modifications because we're operating in this crypto economic setting So first of all auditable safety, right? So auditable safety is kind of like the crypto economic version of visiting fault tolerance safety Now if you look at proofs of security of traditional visiting fault tolerance consensus algorithms So, you know things like PBFC and things like Paxos all that fun academic stuff from the 90s the proofs generally say if This isn't in a basically This algorithm is safe because if it finalizes Well because if it finalizes two and keep high the ball values that can only happen Because at least a third of the participants in the network were dishonest We're at least a third of the participants in the network acts in malicious way, but Here we have a strong we have a stronger condition We don't want to just have a Situation where if the protocol fails then at least a third of malicious We want to have a situation that says if the protocol fails then at least a third of malicious and we know who to blame Right, so that's actually slightly harder and in fact if you use a synchronous BFT protocol So if you use a protocol whose safety depends on a bound on network delays Then you actually can't unambiguously prove who is faulty And so you can't get to kind of this auditable safety requirement if you use algorithms that are safe under a synchrony Then it turns out there's a there's an argument that you can basically convert any Algorithms from the old model into algorithms that are secure under the new model by adding kind of the right layer And the right kinds of hashes and signatures to it And basically the way that this works is that if you add the right kinds of hashes and signatures You can kind of exhaustively enumerate all the kinds of faults and you can prove that any fault is Either a fault that you the fault that you can unambiguously blame someone for or it's a fault That's based that's equal that you can kind of mathematically consider as being equivalence the network latency I mean, so that's kind of where the reasoning comes from Why possible liveness so possible liveness basically means the algorithm does not get stuck, right? So you imagine in order to satisfy the first condition You're going to have to have some mechanism for penalizing validators for doing things that are bad But you don't want to run into the opposite problem where if you have an algorithm That's badly designed and then you could imagine that you know if this This algorithm might accidentally get into a situation where it doesn't it hasn't finalized anything And it can't finalize anything be without some portion of the validators voluntarily violating. There are these a Penalization conditions and voluntarily sacrificing their entire deposits, right? So if a protocol had that property would also be bad So here we have kind of possible liveness which means that basically the protocol can't get stuck There always exists a path toward finalizing something they're always exist a path toward kind of finalizing and agreeing on some block So that's a bit of an introduction to have the latest branch of thinking about Casper Here's a bit of an introduction to some of the latest thinking about sharding, right? So In a shard and blockchain one of the most difficult problems that you have to deal with is something called the data availability problem So basically the idea is this if you think about a non shard and blockchain So any blockchain that exists right now This actually isn't an issue because you can just full nodes can just download an entire block and they can Validate themselves that a block is fully available In a sharded watching you have basically the definition of a sharded watching is a Blockchain where there is so much data in it And there is so much new data that is being constantly produced That there is no way for a single a single node to be able to download and verify all of it You know like you could imagine ether scan having some servers that can download and verify all of it, but not regular users Right, so then the question is how does a regular node actually verify data availability? now Here's one of the reasons why this is hard if data is available, right? So if you had some magic oracle that you can use to prove to kind of mathematically prove that some data is Accessible and anyone can download if they need to then proving correctness So proving validity properties is actually something that you can do with interactive protocols Right, so you can use various kinds of interactive verification You can use kind of crypto economic binding research. You can use various fancy techniques beat to Where if someone does come up with something that's faulty basically the network kind of comes together and generates a Crypto economic proof that says here is something that's worth point that that you should that everyone should look at and and and and verify and You know it Because of this kind of crypto economic pointer everyone every rule the network sees. Oh wait There has been there is an alarm here I should check this thing and everyone can check for themselves. Oh wait There was there was a mistake here, right and the person who made the mistake gets penalized So the problem is with data availability You can't really do that and here's what basically data. They'll unavailability is not a uniquely attributable fault So Basically, you know if if someone makes a block where the data is unavailable You can never unambiguously prove that it was their fault and this is the reason why Consider two cases case one node X publish data D at time t3 When they were supposed to have published it at time t1, right? So they were supposed to have a time t1 instead. They waited until time t3 and There were some node y and that you can think of that node y as being a watchdog node or I can gas that terms a fisherman or you know other kind of Cryptoeconomic Policeman whatever you analogy you want to use and You know, you can imagine known and known why Correctfully raised the alarm and notified you at time t2 that the data is not available. That's case one now Here's case two node X correctly published the data at time t1 as they were supposed to but node y is a crooked cop node y published lied at time t2 lied and Claims that the data was unavailable even though in reality the data was there These from the point of view of a node that looks at the situation after time t3. These two situations are completely indistinguishable so This is the challenge, right the reason why you can't use of these kind of cryptoeconomic Techniques to zero in on data. That's unavailable is because once you start zeroing in on the data The attacker can just be suddenly make the data available and then like the rest of the mechanism Looks like it's trying to conduct it in our service attack, right? So there's this kind of basically you're stuck with either having a mechanism that doesn't work or having a mechanism that can That can just be exploited over and over again as it's an adversarial specter. So this is a fundamentally hard problem So one problem in a shorted blockchain is how do we finalize a state when we can't personally verify its correctness, right? Or when you can't so from the point of view of computation you can use interactive games You can use challenge response protocols. You can use cryptoeconomic binary search or you can just do as you get snark for data availability What do we do? So far there's two major kinds of solutions that we've thought of so far One of them is to rely on an honest minority assumption And so what an honest minority assumption means is Basically, you will assume at least 15% of the network is going to be honest Then you have a protocol that's that says, you know Basically 15% of some randomly selected set of validators that's responsible for some given shard Can just hold it back from being finalized forever Now they have to now if they keep doing this they get penalized for it, right by but the kind of intention here is that You know, we expect these 15% to be honest and we expect we expect them to Prevent any any kind of bad block from being finalized Now this has a problem right one of the problems is that If first of all being part of this kind of altruistic 15% is expensive So what's not clear exactly how sustainable this assumption is and the second thing is that if There is This also opens up a another kind of denial of service vulnerability where a malicious 15% can hold back finality forever Now you could argue that this actually is well You could actually come up with mechanisms where in order for the malicious 15% to do this Basically it becomes very very expensive and you can come up with mechanisms where this kind of attack is always more expensive It has worse trade-offs for the attacker than just making easier attacks like spamming the blockchain with transactions But it's still kind of an issue right the second approach is to use the ratio coding So what do we do here? Right basically the idea is that Instead of using these kind of weird crypto economic tricks to try to can make Make sure that data is available without without people checking whether it's available We would we have actually have every node try to check the availability of every piece of data Now it's a shorted blockchain and in a shorted blockchain There's too much data for everyone to actually check and fully download directly So instead of what we do is instead of doing the full check we do a spot check, right? so basically every node randomly selects a few a few branches tries downloading the branches and Only if all of the branches pass so all the branches download correctly is the node going to accept that block as being legitimate now, so basically it's It's a fair random sampling It's a fairly kind of standard cryptographic technique used in a lot of situations You know if you if you do this kind of approach where you for every block header You kind of randomly poke poke at it in a bunch of places and all of the pokes come back with data Then you know that most of the block is probably is almost certainly available Now this scheme by itself has a problem, which is you're really in a blockchain You really want the data availability to be 100% availability, right? 99.99% is good enough because what if the remaining 0.01% is the DAO, right? What if you know you have a DAO which is one contract and that DAO has 200 million dollars in it and Some attacker comes along and presents a block where they suddenly make you know the the state of the DAO Unaccessible right that even though that might only be 1% of the of the blockchain state or even 1% of a state of one chart That that's still unacceptable, right? So this is why we need to raise your coding I mean so with the raise your coding basically you can kind of expand the amount of data in a block such that as As a long as at least 50% of the data is present that 50% can be used to reconstruct the entire 100% So if that's the basic idea so Open problems, so this is stuff that we are thinking about right one of them is optimal properties of consensus algorithms How do we design consensus algorithms that have the best properties possible highest security margin lowest cost best prob best performance under various economic models Censorship resistance, so the challenge of censorship resistance is that censorship is not is a fault that's extremely difficult to detect right if you see a blockchain and Someone claims that they're being centered It's actually very hard to detect whether or not they're actually being censored So for example, let's say that I said a transaction in this transaction has a fee of $1 Here's how miners could potentially trick everyone else Miners could pop themselves send a bunch of transactions into the blockchain All of which have fees that are higher than $1 and make it look like my transaction never got included Just because the fee wasn't high enough even though actually they were discriminating against me Now even if you can't do this what one way of solving that problem is by making fees mandatory and burning burning part of them Even if you do any kind of various tricks a node that logs on later on Can't can't tell when a transact when a transaction was published, right? So I know that logs on later on can't really tell whether or not censorship happens in the past It can't now it can't tell if their censorship That's ongoing because once a node does log on then it can tell whether or not transactions are being included on time But for stuff that happens in the past you can't tell but so This is a hard problem maximally accurate time stamping So for a lot of applications even if if you look at kind of high-frequency things payments financial applications You want to have a clock that's as accurate as possible now the Ethereum blockchain is kind of okay Because you kind of have blocks every 14 seconds and it's it's hard to cheat on the time stamps by more than a few minutes But it's still not perfect right so the question is can we have Sometimes stamping some kind of clock that's much more accurate So can we use you know things like sequential proof of work? Can we come up with like some kind of much more accurate clock scale both allegations? So this basically is how do we make sure it won't change and particularly? How do we most optimally and actually solve the availability problems? So if anyone here has answers you are welcome to join the research team. Thank you I would say it's it definitely is very new I mean, I think with some of the work that's being done by myself and Vlad It's definitely getting more rigorous over the last couple of years It's not yet at the point of having kind of Fancy PDF academic papers written in latex to get submitted to journals, but I think I mean well, okay To some extent it does some extent it's getting there right so for I would argue that like any paper that was written about incentive analysis of watching protocols is crypt economics to some extent but like Actually formalizing the foundation and like all again and not getting everyone to agree on all these concepts is still a work in progress Yes Right yes, so any you are correct that any kind of protocol that does try to punish actor Punish actors in this way does have what's called a greeting offer opportunity, right? So basically a greeting opportunity is when you can cause other people to lose money But but at cost at some cost to yourself, right? So in any of these situations if like if you create a one of two faults per year one of the two you lose a dollar They lose a dollar So we often analyze this in terms of in terms of the size of the griefing opportunity So how much money can you make people lose and the greeting factor? So if the griefing factor is three that means that if you spend one dollar you can cause other people to lose three dollars In these cases the griefing factor is often often one now the question of can this be used to kind of either a Like harm other participants or drive specific participants out or do other nasty things the answer is yes But like as is always the case in crypt economics you can always do bad stuff You just out you just pay some cost for it, right? So the important thing that you have to keep in mind though is that you want to make sure that You're not accidentally designing the protocols in such a way that Kicking another actor out of the system immediately translates into a profit opportunity for you, right? So for example, like Bitcoin and Ethereum in my opinion may be steerable mistakes in that they have a Reward this situation where the total reward paid to the miners is the same regardless of the protocol quality And this basically means that if you can kick someone kick a small miner out, then you are directly profiting yourself, right? So the best the good crypto economic design involves making situations where even if you Situations where you you kind of maliciously acts to reduce the experience for a for other Participants in the network is not something that that directly makes you money and should be something that directly costs you as much as possible Yes Correct, but okay, so the way that nodes are so to some extent this does kind of depend on now what What the kind of implied protocol is right because for example with Bitcoin the sort of theoretically correct behavior Is that you're supposed to build on top of the first spot that you saw in a theory on what you're supposed to do? Is it supposed to choose randomly 50-50 and the reason why this is the case is because it was part of a fit as Part of a recommended solution that was given to us by the academics at Cornell to reduce our vulnerability to selfish mining now big in what you it definitely is the case that Whatever kind of the initial rule is you could decide I'm not going to follow that rule I'm going to follow my own rule and what you could call you could call that a fault, but at the same time you could it's Also, I mean first of all, it's not really an attributable fault because it's Like this sort of thing and it's based on private randomness like you can't really blame someone You can't prove that someone else is actually faulty if they did this and the second thing is that it's like just in my opinion So far there isn't really enough there isn't really a consensus that Following some rule other than default rule actually is something that's faulty like the it's So far like I think there's a lot of people that just have the opinion that if there are multiple competing Loggies change you should just have a choice of which one you pick and that's fine But you know if we really want to kind of be a stick over for what you really should follow Yes, you could think of it as being a fault, but it's one that's extremely difficult to attribute. Yeah There's not really a formula it's more intuitive look basically the idea is that it's like you have to chew yeah If you choose 15% that means that you're trusting 85 Like you're you're trusting that there's not going to be a situation where more than 85% screw you over But yeah at the same time you're also giving 15% in the ability to meet your life moderately difficult if you go up from 85% to 99% then You have a much much stronger margin on one side But on the other side it becomes really cheap to just like basically stop the blockchain from moving forward So that's the trade-off Like So they're in in proof of work Ethereum they're already are like clients So there is a there is a client called left and another one called status And what they actually are like clients and what these are things that are already in their alpha stage And if you want to you can use them Now then there are protocol improvements that are in the pipeline that would facilitate meeting better like clients So for example in metropolis, there is a planned improvement proposal that would allow life clients to be more secure by kind of probabilistically validating the header chain instead of fully validating it And in proof of stake you can also do a lot of various tricks to try to make the like client protocol stronger But like in general I would say at this point the like line technology is very far along Because I would highly recommend you like download status and try it out. Yes Yeah, so well, it's So there's a different kinds different kinds of of models, right? So there's some models that are kind of fully crypto-economic. There's some that are partially crypto-economic There's some that are that kind of assert furious kinds of imperfections in Either like people's thinking or in people's abilities to coordinate There I mean in general my preferred methodology is that I want to build protocols that are secure both in the crypto-economic model and in a two-thirds on this majority model and You know, there's also a lot of models that were one kind of hybrid approaches. So like this honest minority plus kind of Coordinated choices what is one option that's fairly popular my kind of general actual beliefs on this is that like it definite reality it definitely is At some in some cases approximated by honest majorities though in some cases their honesty has limits So for example, if the protocol tells them to just burn all their money then they're probably going to be dishonest fairly quickly but and in some cases though, I do think that these kind of Crypto-economic bribing attacks are fairly realistic and the reason why I say this is because Oftentimes they don't look they don't the bribes don't even actually look like explicit bribes, right? No one actually says well, haha I'm really giving $50 to wreck the protocol instead. They say oh I am going to open up a new mining pool and this mining pool is going to pay 5% more than all the other mining pools And I'm gonna I'm not gonna and I'm not gonna tell you that that five extra 5% is a bribe for me I'm just gonna make the mining pool 5% better and I'm paying in the 5% quietly and then when I have enough hash power I'm gonna break the network. Well, this is a totally plausible attack vector And you could imagine, you know, if for example, like one thing that people like often like doing is coin voting, right? Where if you want decentralized governance of a blockchain, let's just have like everyone vote on it on it Problem is voting works well in an uncoordinated choice. It works for an uncoordinated choice. It works terribly in a bribing model And the bribe in a coin voting model is basically you could imagine, you know people come creating either exchanges or kind of interest-paying banks and incentivizing people to throw their money into them and once and then, you know, these These parties will just end up Kind of there will be kind of this hidden catch that if you're using this wallet Then, you know, they would basically button vote on your behalf and what you're really doing is you're kind of selling Oh selling away your she kind of your share in the voice in the system because like that's something That's kind of more of a public good than a private good. So, you know, like in general I think the real world is variable enough that it's really worth looking at all the models Yes Yes, they're actually already available I forget the link Yeah Actually, I think if you like scrolled if you go on to my reddit profile and you scroll down a couple of pages Eventually you have a link. It's a PDF on Vitalik.ca. If anyone wants to kind of sort through it that way Yeah Vector Okay, so there is so there is two major classes of objections to proof of state One of them is called nothing at stake and this is the thing that you're talking about, right? Um, and there's also a second one that's called steak grinding But that's actually an attack on specific kinds of bad random number generators and that's Much in my opinion, it's like a less fundamental and much more technical thing and like modern algorithms I've already figured out how to deal with it But with nothing at stake the idea basically is that older proof of stake algorithms So things like pure coin things like most of what Actually, like what even what most proof of state cryptocurrencies are using now They have they do not use penalties, right? They actually all only use rewards and proof of stake without penalties does not doesn't really work well because Basically, if you just kind of try and naively simulate proof of work and you just give people rewards for making a block That's like on on top of the chain Then you then if at any point there is a fork You have the incentive to make a block on top of every possible chain at the same time because you know Oh, there's always some chance that this chain wins and I might as well try and claim a reward inside of it. So That's Roughly why? Go the idea behind nothing at stake attack, you know the bribing portion of the attack basically says if you're an attacker then you can kind of you can bribe people epsilon to create blocks that extend your chain and Basically as long as your bribe kind of exceeds how altruistic people are then everyone's just going to make blocks on top of your chain Your chain is going to grow to be the longest Even if it's reversing like if you're a longer number of blocks and blocks and transactions the way that Basically these things these issues are all dealt with in modern proof of stake protocols Because they do rely on penalties, right? They do rely on basically penalizing validators for making a kind of basic for equivocating for kind of like making blocks that are Or making messages that are contradictory with each other and that's what's also nothing in stake issue