Introduction to Cryptoeconomics - Vitalik Buterin

Great, thank you. Um so a lot in a lot of the time people ask uh ask me to give presentations about things like what is the progress of Casper or what is the progress of sharding or you know in general what what are future versions of the Ethereum protocol going to look like and when are they going to get there? Um but to that question, the answer is they get there when they get there. But today what I wanted to talk about is uh go a bit deeper down and give a bit of an introduction to some of the kind of thinking processes, some of the reasoning that goes into uh the yakka the ways that we've been uh 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 uh blockchain protocols in uh in general as being a part of this category of uh of 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 uh 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 3 years.

But the thing that's really unique about what what's some people call the blockchain space is that it mixes together these two ingredients, right? It mixes together cryptography and economic incentives. So and I'll describe what a blockchain is in in those terms a bit later on. Right? So basically I 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 main kinds of building blocks that we have are 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 and have a message that includes a hash of another message, then that proves that that second message came before or 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 or that where those incentives are defined inside the system and administered by the system are used to encourage the 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 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, you know, 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 Ethereum as 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. Um and the transactions affect the state, right? So, you know, if the state before said that I have $100 and I send a transact or I have 100 Bitcoins and then I send 70 Bitcoins to Christian, then 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 timestamps, and those timestamps are ideally supposed to roughly reflect reality. Now, here are 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 can never get replaced, you never have reorgs, you never have 51% attacks. Every time a block comes and goes and gets goes onto the chain, it stays on the on the chain in that exact same place forever. The next block gets added on top of that, the next block gets added on top of that. Um validity.

So, the we want the you know, the Bitcoin blockchain to be valid. And here are some uh definitions of validity. So, there's lots of def- lots of definitions of validity. One of them is that, you know, you want proof of work to be valid, you want blocks to contain hashes of the previous block, you want things to be in the right format. Um also, uh an important one from the point of view of a currency is that you have a validity predicate.

So, only transactions that satisfy some validity predicate that depends on the transaction, and also depends on the current state, um should be included in a block. So, for example, if the current state is that I have 100 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 that transaction fails. Um also, the clock should be roughly increasing. Right?

So, that's like that's one partial condition for kind of the clock reflecting reality. Right? Like it doesn't cover everything because the clock could potentially increase like 10 10 times faster than real time, but the clock should def 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 available uh valid, it also needs to be available. Everyone needs to be able to download the blockchain when they want uh if if or when they wants 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 Merkle tree and download the rest of that block.

Now, theoretically, you could imagine a malicious minor mining cartel decide to publish a chain of block headers where the blocks that those block headers 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's valid, even though they're following all the other rules, this is still bad and this is still something we want to avoid. Um availability.

So, this is availability of the protocol with with respect to users of the protocol. If you see I have a transaction, that transaction and that 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, like you don't want like you don't want a system where, you know, even if you pay $100, it refuses you. Or, you know, you don't want a system that just like outright discriminates against certain classes of actors. So, you know, we have a 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 in the consensus mechanism in some sense.

Signatures. So, signatures prove who sent the transaction. And hashes. And hashes have certain purpose 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 and you have blocks and then the blocks are in this exact order and no, you can't kind of take a block out in the middle and replace it with something else. And another function that hashes have is they enable a kind of limited light client protocol with Merkel proofs, right? So, basically, if you have a Bitcoin client on a phone and you only want 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 verify that 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 structures, you can actually do this. Um incentives.

So, the miner of a block that gets it into the chain gets 12 and 1/2 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 to get it into the next block, it 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 miner doesn't include your transaction, some future miner might. But even still, like this this privilege actually does end up being part of a miner's incentive, right? And the basic Now, then um if you create a block and that 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 just going to end up being roughly the same.

And this is important. And what particularly this actually is one of the main reasons why Bitcoin has selfish mining vulnerabilities. Um so, cryptography. So, we can think about cryptography here in generally, right? So, hashes, I mean they have several functions.

Um 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. Um also, hashes can do other things. So, they enable these like these data structures that you can kind of crawl through and down verify very small portions of.

Um they um allow in general allow for small pieces of data to kind of stand in for big pieces of data. Um signatures um 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 a very long time to verify 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 even 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 a certain amount of expected computational effort. Right?

So, if you make a proof of work, then on average a certain amount of computational effort was extended expended in order to create it. Erasure codes. Um 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 1 GB of data, then I can use this erasure coding algorithm turn it into 2 GB and what the algorithm gives you is any 1 GB out of those 2 GB even if it's like a GB 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.

Uh time-lock crypto. So, this is an interesting tool in the toolbox. Basically, it allows you to prove first of all proof topological 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. Um homomorphic encryption and 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?

And 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 their outputs, what do they do, what properties do they have? So, it's and some this part is in some ways a more simpler task than being a cryptographer actually involved in creating these functions. Now, economists, 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. 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, the Bitcoin protocol can just assign a miner 12.5 Bitcoins as a reward for creating a block. The Ethereum protocol can assign you five ether if 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 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 where those decision-making rights can be used to extract rent. So, what do I mean? Now, remember think thinking back to um mining, right? So, when you create a block, you are a dictator over transaction equations or in that block.

If you want a transaction to be included, then you can include it. If you want a transaction not to be included, you cannot 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 an intended part of the incentive structure behind how Bitcoin works. And behind how Ethereum works, and behind how any blockchain in general works. Now, you can also you can give people privileges, you can also take privileges away as a penalty. Um so, this is the other way of categorizing rewards or categorizing incentives. Rewards, and a reward basically means if an act 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 is actually written incorrectly. It means you it should say you should or you can take their future privileges away. So, here's some some other important concepts. 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 satisfies some guarantee, or the the guarantee is broken, but some actors in the in the in the system, those malicious actors that caused G to fail, and end up paying either paying an amount of money X or forgoing some amount of revenue equal to X in order to make that make that property not uh fail.

Right? So, you can think about like a crypto-economic uh security margin on, you know, the protocol uh staying like uh the blockchain being convergent on uh uh somewhat finality mechanism being broken, on, you know, any kind of mechanism that you create having the intended effect. Um so, but in general, like the idea basically is that you can measure security in dollars. And a 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 have Basically, what this what this is 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 a a some amount of money in order to trick you.

So, one example of this is uh if you think about proof of work in the context of a light client, you can think of a block that gets created as being a crypto-economic proof that the the block points to something which is in the main or in the main chain, and that the block itself is part of the main chain, where you get where the predicate P basically is a a kind of being part of the chain, and the economic loss of size X is basically the the block reward. Right? Now, in proof of stake, you can imagine crypto-economic proofs where you know, 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 in other 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's some security models that just say, "We expect 2/3 of the participants in the network to be nice guys." And, you know, this is called This is called uh Byzantine fault standard Byzantine 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." So, and that's uh 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 choice model assumes that all participants in the protocol do not coordinate with each other. They have separate incentives and are 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 a 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.

Uncoordinated choice model. So, that's a model that basically assumes that all actions in a protocol are are controlled by the same agent or controlled by the same coalition. Um bribing attacker model. So, this is a model where you have an uncoordinated choice assumption, but it also assumes that there is some attacker, 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 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, Schelling Coin. Right? So, a Schelling Coin protocol is this kind of simple but naive 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 the reward, and everyone who voted the same answer as the minority gets nothing. So, that's the algorithm, right? Now, you in an honest in an honest majority model, is this algorithm good? This is the question just to check how people are following along. In an honest majority algorithm, does this work?

Yeah. Okay. And this works 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? Right.

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. You know, it's not the only equilibrium, but it is an equilibrium, and if the system is in this equilibrium, then it's, you know, it's an equilibrium, and then it can stay in this equilibrium. So, now we let's try and think about about this in Actually, before I even get to this, we can think about this in a coordinated choice model. So, in a coordinated choice model, you know, it does basically does this work, right? Um any ideas?

Uh 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 * P. If they all vote for B, they get a reward of N * P. So, now you Now, what you could say is that you could say that, you know, if the participants in this network care about its 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 if A is the correct answer than if B wins. And this is a kind of public good that's spread across all the participants.

So, you could imagine that if you would start try to include these kind of goodwill factors that in in the coordinated choice model does have some security. Now, let's look at the bribing attacker model. So, this is the kind of infamous P + epsilon attack that Andrew Miller came up with about 2 years ago. Basically, a bribing attacker can corrupt the Schelling coin game with a budget of P + epsilon and a 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 vote zero, you get the reward. If you vote one others vote 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 bribing attacker adds this columns this block this extra reward here into the matrix. Basically, what the attacker does is he is he says, and you know, this could be cryptoeconomically enforced, 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 votes zero, then I will compensate you P + epsilon. Now, if you vote one and the majority also votes one, then then I'm going to pay nothing. But, if you go with me and you vote for one and and you're not you end up losing, then I'll compensate you and I'll and I'm going to 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 going to do.

Now, there's only one equilibrium because no matter what your beliefs are about how others are going to vote, you voting one has a higher reward than you voting zero. And so, everyone votes one and so the attacker actually ends you end up in the bottom right square. So, the attacker actually ends up paying nothing. Right? So, that's what I mean by a budget of people's up so on versus a cost of zero.

You have to be willing to pay people's up so on, 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 different responses to many kinds of games. Um proof of work. Turns out proof of work has a a lot of the of the same properties that Schelling 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's up so on attacks on it. Um and same behavior on in uncoordinated choice models and same behavior in coordinated choice models. Now, let's um move on a bit and look at faults. Right? So, faults basically are you know, since you you can and 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. Right? So, you can think about a protocol that does not satisfy some of its desired properties. So, for example, you can imagine you have the you know, a blockchain then that instead of the at some point instead of you know, instead of the blockchain adding another block, the blockchain kind of doubles back three blocks and makes an and it kind of forks off. And those three blocks that were originally there just kind of end up disappearing off of off into nothing or getting included it uncles or whatever else.

Right? So, that's a deviation from optimal behavior because, you know, a transaction it looked like the chain was going this way, but like actually it turned around and went in and went 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 bribed to do various things, and faults of the network. So, networks might have latency, or networks might that uh you know, just like cannot let certain messages pass through.

Um or potentially might get a uh you know, in a a kind of worldwide partition. You know, you could imagine if uh World War III starts and a bunch of undersea cables got to get cut and, you know, the US and Eurasia split off into their different internets, that's also a network fault. Categorization of faults, right? So, one So, here's one way where we can categorize faults, at least faults of individual faults and faults of 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 it's a function that takes a set of messages you already saw, the um or and plus when you saw them and then the auxiliary data, and it and it outputs either nothing or some message that you're supposed to send. So, here's how we can categorize faults. One of one thing we can say is one kind of fault is invalidity.

Right? So, invalidity basically means a node sends a message where that message is not the result of executing the protocol for any um subset of the messages that the node actually saw. So, basically the node is just like not running the program at all. It will 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 done the software equivalent of that. So, for kind of any reasonable aux or for any subset of the messages that the node actually saw.

The next one is equivocation. Now, you can think of equivocation as being kind of like your program forking, right? So, basically 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 faithfully following the protocol as if you saw 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 doesn't look like a straight line.

It looks like you got to saw some things, but then you forgot them. So, this is called equivocation. Um 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. Um using false values of aux. So, for example, if Trump won the election, but you decide you uh for either you really don't like Trump or you want to screw around with the system, you proclaim in the showing coin game that Hillary won the election. Um special case. Remember, part of aux is time, right?

So, sending messages too early is a special case of this. And another one is 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 there's other protocol faults where you have clear cryptographic evidence that says, you know, a fault happened. 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 uh network fault, right? Now, given that kind of fault, or given a fault that we can unambiguously identify, we can often, inside the protocol, narrow 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 fork, right?

So, you have, you know, you have your network, the miners are just happily trudging along, and la la la, la la la, yeah, we have a happy happy blockchain. Then you have block A. Then, uh-oh, on top of block A, you have block B and C, and on top of block C, you have block D, and presumably on top of block D, tra la 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 B ignored C and D, right? So, B saw C and D's blocks, or B saw C's block, but B said, "Eh, screw you, I'm just going to build on top of A." This could be because B just really doesn't like C, or this could be part of a selfish mining attack, or this could be, you know, because B's computer was corrupted, lots of lots of different reasons, but the point is that he is in on it it is a fault of pretending not to receive messages. Case two, C ignored B, right? So, it's entirely possible that B made a block first, then C saw that block.

C could have built on top of it, but C instead said, "Eh, screw you. I'm just going to build on top of A." And then D had a binary choice between B and C, and D just happened to pick C. Case three, C did not send to B, right? So, C created a block, but C said, "Uh you know what?

I'm not going to send this block to these other miners. I'm just going to keep the block, and maybe I'm going to send it to D cuz he's my buddy." And so, that's also a fault. Um case four, B did not send to C, right? So, maybe B created a block, but B's like, "Eh, I'm not going to send that block.

I'm going to try and selfish mine or whatever." But in B ended up ended up not sending the block. C ended up creating a block creating their own block, and D ended up and D ended up just built on top of C. And 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 an uh 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 does this imply, right?

So, what here we're going to start looking at some of the kind of principles of cryptoeconomic penalty assignment, right? So, basically, if you have a fault and that fault is 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 should 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 margin. Now, let's say you can't choose. Let's say you know it down to one of two people who's guilty, but you don't know which one. Now, one thing 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 they both lose 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 griefing opportunities. So, a 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 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 blamed D. But, B and C were each blamed equally, right? The blame was the fault the fault possibilities were symmetrical. For every story where B is at fault, there was a corresponding story where C is at fault.

And so, by the principles of crypto economics 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 he's 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 saying that in according to the crypto economic principles of penalty assignment, which are which are better than the holy book of Satoshi, we can create a set of uh 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 mining. So, the Now, why is this better under the coordinated choice model, right? Any ideas? I'll I'll give you a hint.

Um property three, pay for performance, basically is like an exact synonym of be working well under the coordinated choice model. Uh 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 coordinated with with each other, right? And a coalition gen- cares about its total revenues.

And 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 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. Um benefits, if we know someone is faulty, they'll be punished.

Um, innocents 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 selfish mining issues are easier to resolve. So, we can look at proof of stake in this model, right? So, in proof of stake, you have a consensus algorithm, where in that consensus algorithm, instead of using proof of work, it 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 an amount of money, and but you cannot take the deposit out, right?

You cannot take the deposit out, at least without some kind of 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 unambiguously 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 can unlike a blockchain that unlike a proof of work chain that only has convergence properties, basically or that 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, it can't get unfinalized.

It just can't. Right? 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 of proof of work is very high is because or sorry, of proof of stake is very high is because in a proof of work model, the because identities are anonymous, because miners are anonymous, the only way that we have to incentivize miners is by either giving them rewards or or or giving them privileges or taking away their rewards and privileges.

Right? So, basically, if you want to have a crypto-economic for 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, you're people are generally familiar with the notion that you can stick money into a deposit, you can earn interest on the deposit, and you can take the money out.

But, if 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 the interest could potentially be paid entirely in just the ability to block transaction fees. But, so the security margin 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 kind of the basic principle here. Um no pun intended. So, here are some properties that we want proof of stake algorithms to have.

Right? So, this actually kind of follows along with uh traditional Byzantine 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 Byzantine fault tolerance safety.

Now, if you look at proofs of security of traditional Byzantine fault tolerance consensus algorithms, so you know, things like PBFT, things like Paxos, all that fun academic stuff from the '90s, the proofs generally say, "If this basically this algorithm is safe because if it finalizes well, because if it finalizes to incompatible values, that can only happen because at least a third of the participants in the network were dishonest, where at least a third of the participants in the network acted maliciously. But, here we have a strong we have we have a stronger condition. We don't want to just have a situation where if the protocol fails, then at least a third are malicious. We want to have a situation that says, if the protocol fails, then at least a third are malicious and we know who's 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 asynchrony, then it turns out there's a there's an 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 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 a fault that you can unambiguously blame someone for or it's a fault that's based that's equivalent that you can kind of mathematically consider as being equivalent to network latency.

Right? So, that's kind of where the reasoning comes from. Liveness plausible liveness? So, plausible 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, then you could imagine that, you know, if this uh this algorithm might accidentally get into a situation where it doesn't it hasn't finalized anything and it can't finalize anything without some portion of the validators voluntarily violating their these 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 plausible liveness which means that basically the protocol can't get stuck. There will always exist a path toward finalizing something.

There will always exist a path toward kind of finalizing and agreeing on some block. Um So that's a bit of an introduction to kind of the latest branch of thinking about Casper. Here is a bit of an introduction to some of the latest thinking about sharding. Right, so in a sharded 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-sharded 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 blockchain, you have basically the definition of a sharded blockchain 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. Now, like you could imagine Etherscan 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 even 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 it 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 binary search. You can use various fancy techniques, be it two, 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 and verify."

And, you know, the because of this kind of crypto-economic pointer, everyone every node in the network sees, "Oh wait, there has been an there is an alarm here. I should check this thing." And everyone can check for themselves, "Oh wait, there was a 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 avail- 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 published data D at time T3 when they were supposed to have published it at time T1. Right? So, they were supposed to have published it at time T1, instead they waited until time T3. And there was some node Y, and that you can think of that node Y as being a watchdog node or a gas station or a fisherman or, you know, other kind of sort of crypto-economic policeman whatever you analogy you want to use. And, you know, you can imagine node and node Y correctly 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 it lied at time T2, lied and claimed 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 a challenge, right? The reason why you can't use 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 poof make suddenly make the data available. And then, like the rest of the mechanism looks like it's trying to conduct a denial of service attack, right? So, there's this kind of basically, you're stuck with either having a mechanism that that doesn't work or having a mechanism that can just give you denial of service that can just be exploited over and over again as a denial of service vector. So, this is a fundamentally hard problem.

Um so, in one problem in a sharded blockchain is, how do we finalize a state when we can't personally verify its correctness, right? Or when you can't put 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 a ZK-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.

Right? 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 says 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? But 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 luck from being finalized.

Now, this has a problem, right? One of the problems is that if first of all, being a part of this kind of altruistic 15% is expensive. So, it's not clear exactly how sustainable this assumption is. And the second thing is that if uh there's 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 and has worse trade-offs for the attacker than just making easier attacks like uh spamming the blockchain with transactions, but it's still kind of an issue. Right? The second approach is to use erasure coding. So, what do we do here, right? Basically, the idea is that instead of using these kind of weird cryptoeconomic tricks to try to can make make sure the 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 sharded blockchain, and in a sharded 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 a 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 if all of the branches download correctly, is the node going to accept that block as being uh kind of legitimate. Now, so basically, it's uh it's a fairly random sampling. It's a fairly kind of standard cryptographic technique used in a lot of situations.

You know, if uh you if you do this kind of approach where you for every block header you kind of randomly poke it 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 really in a blockchain you really want the data availability to be 100% availability, right? 99.99% isn't 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 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? Now, even though that might only be 1% of the of the blockchain state or even 1% of the state of one shard, that that's still unacceptable, right? So, this is why we need erasure coding. I mean, so with erasure coding, basically, you can kind of expand the amount of data in a block such that as long as at least 50% of the data is present, that 50% can be used to reconstruct the entire 100%. So, 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, um 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 censored, it's actually very hard to detect whether or not they're actually being censored. So, for example, let's say that I send a transaction and this transaction has a fee of $1. Here's how miners could potentially trick everyone else. Miners could pub- 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, like 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 trans when a transaction was published, right? So, a node that logs on later on can't really tell whether or not censorship happens in the past. It can't Now, it can tell if there's 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.

Right? So, this is a hard problem. Maximally accurate timestamping. So, for a lot of applications, even if it's 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 timestamps by more than a few minutes, but it's still not perfect.

Right? So, the question is, can we have some timestamping 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? Scalable validation.

So, this basically is how do we make sure in blockchains and particularly, how do we most optimally and actually solve data availability problems? So, if anyone here has answers, you are welcome to join the research team. THANK YOU. YEAH. WELL, ANY QUESTIONS?

YES, THIS LOOKS LIKE A FAIRLY new field, this whole field of cryptocurrency. How long have you been and how rigorous is the foundation of it? Um, 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. Uh, 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 to some extent it's getting there, right?

So, I would argue that like any paper that was written about incentive analysis of watching protocols is crypto economics to some extent. But, like actually formalizing the foundation and like all and like getting everyone to agree on all these concepts is still work in progress. Yeah. If we cannot mitigate between the two faulty, if we don't know who's the faulty one, doesn't incentivize for centralization? What?

that I we can create an ambiguous attack and make people who are small miners not identifiable and as as long as we punish them, they would disappear because the cost would be too high for them. Right, yeah. 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 griefing opportunity. Right? So, basically a griefing 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 you create a one of two faults where you're one of the two, you lose a dollar, they lose a dollar. So, we often analyze this in terms of griefing in terms of like the size of the griefing opportunity. So, how much money can you make people lose and the griefing factor? So, if the griefing factor is three, that means that if you spend $1, you can cause other people to lose $3.

In these cases, the griefing factor is often often one. Um, now the question of can this be used to kind of either uh like harm other participants or drive specific participants out or do other nasty things. Um, the answer is yes, but uh like as is always the case in cryptoeconomics, you can always do bad stuff. You just 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 that you you're you're not accidentally designing the protocols in such a way that um 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, made these terrible mistakes in that they have a reward the 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 some kick a small miner out, then you are directly profiting yourself. Right?

So, the best good cryptoeconomic design involves making situations where even if you like the situations where you you kind of maliciously act to reduce the experience for for other participants in the network is not something that that directly makes you money and should be something that directly cost you as much as possible. Yes. I have a similar question. Um in your loser poll table, Mhm. how can you exactly explain that D is not at fault at all?

Because I mean, D can make a very conscious choice about not building on top of B's block. Correct. But, okay. So, the way that um nodes are So, to some extent, this does kind of depends on what uh what the kind of implied protocol is. Right?

Because, for example, with Bitcoin, the the sort of theoretically correct behavior is that you're supposed to build on top of the first block that you saw. In Ethereum, what you're supposed to do is you're supposed to choose randomly 50/50. And the reason why this is the case is because it was part of a as part of a recommended solution that was given to us by the academics at Cornell to reduce our vulnerability to selfish mining. Now, 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 like you could call you could call that a fault, but at the same time you could it's uh also and first of all, it's not really an attributable fault because it's uh with this sort of thing it's based on private randomness.

Like you can't really blame someone uh 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 I can't there's a lot of people that just have the opinion that if there are multiple competing longest chains, 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 be a stickler for which rule you should follow, yes, you could think of it as being a fault, but it's one that's extremely difficult to attribute. Yeah?

I have a question about the 50% honest miners opinion. Why 50% is Um There's not really a formula, it's more intuitive. Like basically the idea is that it's uh Like you have to choose you 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 you at the same time you're also giving 15% in the ability to make 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, like that's the trade-off. Yeah. Um do you know whether in the near future there will be any uh light clients for for mobile? Um so, there in in proof of work Ethereum there already are light clients. So, there is a there is a client called LETH and another one called Status.

And what they actually are light clients. And what these are things that are already in their alpha stage. And if you want to, you can use them. Um now, then there are protocol improvements that are in the pipeline that would facilitate making better light clients. So, for example, in Metropolis there is a planned improvement proposal that would allow light clients to be more secure by kind of probabilistically validating the header chain instead of fully validating it.

Um and in proof of stake you can also do a lots of various tricks to try to make the light client protocol stronger. Um but like in general, I would say at this point the light client technology is very far along. Okay. Because I I already used um the light client optional of get. But it would be really nice to have it in nice uh applications Totally.

Yeah, so like that I would I would highly recommend you like download Status and try it out. Okay. Yes. Um so, the cryptoeconomics assumes that everyone is rational. But do you Did you look into like any compensating mechanisms?

Yeah, so well it's uh So, there's a different kinds different kinds of uh of models, right? So, there's some models that are kind of fully cryptoeconomic. There's some that are partially cryptoeconomic. Um there's um some that are that kind of assert various kinds of imperfections in uh either like people's thinking or in people's abilities to coordinate. Um There I mean, in general, my preferred methodology is that I want to build protocols that are secure both in the cryptoeconomic model and in a 2/3 honest majority model.

And you know, there's also a lot of models that rely on kind of hybrid approaches. So, like this honest minority plus kind of a coordinated choice is what is one option that's that's fairly popular. Um my kind of general actual beliefs on this is that like it definite reality definitely is 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 then they're probably going to be dishonest fairly quickly. But and in some cases though, like I do think that these kind of uh cryptoeconomic bribing attacks are fairly realistic.

And the reason why I say this is because often times they don't like they don't the bribes don't even actually look like explicit bribes, right? No one actually says, "Muhaha, I'm going to give you $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 I'm not going to And I'm not going to tell you that that 5% extra 5% is a bribe for me.

I'm just going to make the mining pool 5% better and I'm paying in the 5% quietly." And then, when I have enough hash power, I'm going to break the network. Like 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 you know, if you if you want decentralized governance of a blockchain, let's just have like everyone vote on the on it.

Problem is voting works well in an in uncoordinated choice, it works well in coordinated choice, it works terribly in a bribing model. And the bribe in in a coin voting model is basically you could imagine, you know, people creating either exchanges or kind of interest-paying banks and incentivizing people to throw their money into them. And once an And then, you know, these these parties will just ends up kind of there will be kind of this hidden catch that if you're using this wallet, then, you know, they would basically voting vote on your behalf. And what you're really doing is you're kind of selling a lot of selling away your sheet kind of your share in the voice in the system because like that's something that's kind of more of a public than a private good. So, you know, like in in general, I think the real world is variable enough that it's really worth looking at all the models.

Yes. Thanks. Can you make these slides available? Uh yes, they're actually already available. Um I forget the link.

video page later. Yeah. Actually, I think if you like scroll down if you go on onto my Reddit profile and you scroll down a couple of pages, eventually you have a link. It's a it's a PDF on vitalik.ca.

If anyone wants to kind of sort through it that way. Yeah. And how do you finalize the proof of stake because I read this paper about proof of stake is impossible and they have this attack vector where you bribe the former Okay, so there is so there is two major classes of objections to proof of stake. One of them is called nothing at stake. And this is the old thing that you're talking about, right?

And there's also a second one that's called stake 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 have 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 Peercoin, things like you know, most of what what actually like what what even what most proof of work of 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 rough bit of roughly why the idea behind the nothing at stake attack.

Now, 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 you 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 and your chain's going to grow to be the longest even if it's reversing like a very long of a very long 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 causing nothing at stake issue. Okay.

Okay, one more question then. Let's thank the speaker.