 revolution? How about a mob revolution? Vitalik. Cool. Yay, okay. Where is the clicky thing? Oh, there it is. Perfect. So in the, wait, how does this even work? In the interest of problem, I'll get right to the point. So, okay, maybe I won't get right to the point. Where is the clicker? Ning. So, I'll first let people read the comic that the, that the MOV paper is named after. Although I'm sure lots of you have already seen it. Which colors do you want the blockchain? I think MOV has the most RAM. So let's scale the blockchain. Let's add some more RAM. Let's make the blockchain MOV. So, Ethereum is obviously a, a terrible system. It's a, as Jeff Coleman said, it's a smartphone from 1999. World is trying to process hundreds of thousands of transactions a day. And for some reason, we're trying to convince people to use this thing that can only process 15, or hundreds of thousands a second, rather than we can only process 15. Transactions take 14 seconds to get into one block and minutes to finalize. So when a payment is, when a payment normally takes seconds, the blockchain is minutes away. Very little privacy at base protocol layer. So, clearly not good for anything. Fortunately, that's what the research team is for. We have solutions, we have solutions for most of these problems. So, our main focus in, in research is basically figuring out where exactly do Ethereum platform falls short. And seeing if we, what parts of this we can improve. So, there's different parts to this problem. So, privacy, Zuko made a wonderful presentation on Zcash, and we're going to be integrating lots of that stuff over the next couple of months, years we'll see. But here, we're going to focus on three things. One of them is scalability, one of them is cost, and with a bit of latency. So, and there's also a bunch of other small problems that we have to worry about. Mining centralization, selfish mining vulnerabilities, interfaces on clean, I'll talk, if people want me to talk about this, I can, but not here. So, step one, proof of stake. So, basically, what is the point of proof of stake? The intuition that I generally use to describe it is what I call virtual mining. So, proof of work, you have $1,000, you use your $1,000 to buy a miner, you take your miner, plug it into the internet, plug it into electricity, and your miner has the ability to stochastically generate blocks. If you have a miner of $1,000, you might produce like one block a day. If you put $2,000 into your miner, you might produce two blocks a day. But, in general, put money in, and you make blocks, and rewards for you come out. Proof of stake, take $1,000, convert the $1,000 into 83 Ether, and then convert the 83 Ether into a virtual miner. And the virtual, and then, inside of the protocol, there is a rule that says, if you have a virtual miner, you have the ability to stochastically generate blocks. So, the protocol itself, basically, defines you, or gives you the right to create these blocks, and it gives you the right to create these blocks in proportion to sort of how big your virtual miner is. If you get $1,000 virtual miner, then you can maybe create one block a day. If you have a $2,000 virtual miner, you can create two blocks a day, and so forth. So, same thing as proof of work, but without wasting any actual electricity. So, that's the kind of dream. Now, proof of stake, it's existed since about 2011, solved with the electricity problem. So, here's the approach that we're taking in at least my version of Casper. So, in the state, there is a set of bonded validators. Do people here remember what the state is? It's an evil entity that steals a third of your money and bombs people in third world countries? No, it's a state. The state is the set of sort of current information, things like balances and nonces that you have to keep track of. And part of the state now is basically keeping track of some set of sort of bonded validators. So, bonded validators are kind of active participants in the protocol. And they act of participants in the consensus protocol. Now, if basically the state is the set of people who have virtual miners, the miners are virtual and we are exactly are these virtual miners kept track of or kept track of in the state of the protocol itself. Anyone can join the set by sending a transaction to this contract that's called the Casper contract. So, this Casper contract has a special address. In this case, it's a number 255. And if you send a transaction to it, and this transaction calls the deposit function, then you basically, and if you, along with your call, you send some ether in, then you can become a validator. So, you specify a bunch of parameters called validation code, Randall, withdrawal address, we'll talk about those later. And if you call this function during epoch n, so one epoch is like a period of about 12 hours, then at the start of epoch n plus two, so like between 12 and 24 hours from now, your validator joins the active validator pool. And at that point, you basically, your virtual miner is active. Now, while a validator is inducted, there will sometimes be pseudo randomly assigned the right to create blocks. And the probability at any given time that you'll be pseudo randomly given the rights to create a block is based proportional to the amount of ether that you deposited. Now, in proof of work, a block has to contain a nonce and that kind of proof is a solution to a proof of work puzzle. And that solution, the proof of work puzzle basically proves that you, in the proof of work lottery, you got lucky and you have the right to create this block. Here, instead of doing that, blocks have to contain a signature. Now, what is, and the signature is basically in simplest forms, the signature is signed by the validator's private key, and it's checked against the validator's public key. But one thing that we want to do here is we want instead of having just using a public key, we have this notion of validation code. So what this means is that, okay, well, the validation code is a function. And the function says, it takes a signature, and it takes a hash as input, and it returns zero or one. Now, normally, the validation code might be something as simple as a signature checker. So the validation code basically says, take a signature as input, check it against the public key. And if the signature checks out, return one, otherwise return zero. If, let's say, you as a validator are concerned about, let's say, quantum cryptography, let's say you think that the NSA, see, you know, as an arm, the pervasive arm of the state that it is, has access to quantum computers, and it can break public elliptic or signatures in an instant, then you might want to switch to lamp or signatures, lamp or signatures or type of signature that's quantum resistant. And if you care about that, then basically you don't have to wait for the protocol to hard fork. You can just switch to it yourself tomorrow. So a validator can also call start with draw to withdraw. So one of the differences between real miners and virtual miners is that with virtual miners, once you're done mining, you can actually sort of can unfreeze the miner and sort of turn it right back into liquid ether. So it's not a one way process. If you're done mining, you can call this function called start withdrawal, and you withdraw and then one or two epochs later, you are no longer part of the active validator pool, you can check your note off and you can stop creating blocks. Then you have to wait a bit more. And after waiting a bit more, you can withdraw your deposit plus any rewards that you earned minus any penalties of the protocol assigned you for acting incorrectly. So this is basically your experience as a validator. Take ether, call the deposit function. After 12 hours, you become a validator, you have to keep your note online, make sure create blocks to when you whenever you get assigned the right to create blocks, keep that thing online. Then when you get bored, call withdraw, then after another 12 hours, you can shut your note off. And then after another some point in time, this might be something like a few months, you can take your you can call withdraw and you can take your e throughout nice and simple. So people, according to some people, there are supposed fundamental flaws and proof of stake. So let me go through some of them. So one of the main problems is validator selection. So the challenge is, how do we choose which validator creates the next block? Now, in proof of work, the problem is kind of solved automatically because well, one validator just like randomly solves the puzzle and gets lucky. Here we don't have that here we have kind of virtual mining. And so we have to simulate randomly assigning validators the right to create a block. So the state grinding problem basically says there may exist an economic incentive for a validator to perform computations do various things to try to manipulate validator selection in their favor. So if let's say you as a validator, you have 1% of like the total active, you are 1% of the active validator set. If the algorithm is fair, you should be creating 1% of the blocks. But if you can manipulate it, maybe can manipulate your way to like getting 1.4% of the blocks. And if you can do that, then you have the incentive to spend anywhere up to 0.4% of the total block rewards in order to get yourself that privileged position. So here's some examples in like one old NXT algorithm, validator was pseudo randomly sampled based on the signature of the current block. So the attack vector there is basically to just grind a bunch of signatures until you find one that favors you. Another in some other older proof of stake algorithms, the incentive was actually to find a favorable address to move your coins to so you can figure out which address you can move your coins to. Where that address would get assigned a block fairly soon, move your coins to it, get then get make the block and then immediately move your coins to another favorable address and so forth. So these issues are fixable. So for example, the address moving issue we fix by just requiring people to kind of deposit their ether well in advance, and by kind of having this sort of long lockup period, and the long withdrawal period, so you can't just like move coins around quickly. So the other problems are solved by basically having a kind of by having a validator selection algorithm that actually is fairly economically robust. So in general, this problem actually is solvable. So you might hear arguments that say things like marginal cost approaches, marginal revenue or whatever. But the point there's several different caveats to this. The most important one is that it's not enough to say that if you can't exploit it, people will you have to show that the algorithm actually can be exploited. So the arguments that I can make is we have this approach where basically the random number generation is for validator selection is based on information that's not yet available. So information that validators have committed to by basically submitting the hash, but where the validators reveal the information while creating a block while creating their block. So block n contains basically contains this random number that gets revealed. This random number can only be one particular thing. There's no choice about which number you reveal because it gets checked against something else that you submitted previously. But once you submit that value, then that becomes a source of randomness for the next block. And then whoever creates the next block is going to reveal their value. That's the source of randomness for the next block and so forth. So the argument here is, yes, you can manipulate it, but there's two ways to manipulate it. One of them is, well, you try to manipulate what your original commitments are. The problem is that that's when you're choosing what your original commitments are. It's like so far back, and the validator selection is going to be based on so much future entropy that you have no way of predicting which direction of manipulation is going to be in your favor. The other way you can manipulate it is by not producing a block. So you get the chance to produce a block, but then you see, oh, well, I might produce a block, but I might not produce a block and that'll benefit me. But the problem is that that has a cost. And the cost basically is if you do produce a block, you get the block reward. If you don't produce a block, then you don't get the block reward. So the number of opportunities where manipulation actually is more profitable than the cost is very small. So another problem is, let's say we select a validator. Let's say the validator is not present. So what do we do? Well, obviously, the blockchain can just stall and we can all go home, right? OK, Ethereum's done. Go back to Ethereum Classic. So what we do instead of selecting one validator, we select the sequence of validators. So basically, we select an infinite sequence where if validator 0 doesn't show up, then after some point in time, validator 1 can create a block. If validator 1 also is offline, then validator 2 can create a block, and so forth. So this is actually fairly standard. So NXT works this way. A lot of existing proof of stake algorithms work this way. So this is not particularly novel and generally is the standard way that this sort of stuff is done. In my opinion, there are some sort of incentive issues that should be researched more regarding whether or not timing is incentive compatible. But in general, at least in practice, this has worked fairly well. So next point, let's talk about nothing at stake. So nothing at stake is this other reason why proof of stake is terrible and can never, never work, which is why we should just give up and go back to proof of work. So basically, here's the problem. So in the normal case, you as a minor have four choices. Let's say there exists a fork. Let's say there exists two blocks, A and B. Let's say you as a minor think that block A has a 90% chance of winning, and block B has a 10% chance of winning. Option one is you just mine on neither of them. And if you do that, you get no reward. Option B is you vote, or I should say option one is you vote on neither. Option two is you just create a block on top of A. Now 90% chance A is going to win, you're going to create a block on top of A, and you're going to win with them. The option three, vote on B. B only has a 10% chance of winning if you create a block there, then you have a much smaller chance of getting a reward. Option D is to split your vote between both, but if you split your vote then you get, because you have to actually split your work in half, you get only half of one and half of the other. And so it turns out that the best choice is to just vote on A. Now, this is actually good, because what this says is if a block is winning, it's in everyone's incentive to help it win even more. So this is basically the proof of work as an economic consensus game has a nice convergence property. So this is the sort of thing that we want to have in virtual mining as well. Now, naive proof of stake economics, so this is how the older proof of stake algorithms worked. Okay, vote on neither, zero. You can make a block on top of A, okay, 0.9. You can make a block on top of B, 0.1. Problem is, now you can create a block on top of both. And the problem is, because you no longer have computing power as a limiting factor, you don't actually have to sort of split your vote in half. You can literally just make a block on one side and make a block on the other side. In which everyone wins, you profit. Yay, so everyone actually, even if there are no attackers, everyone has the incentive to create a block on every single chain at the same time. And therefore, in an economic incentive model, a thing just never converges. So this is the problem. So in, we've had the solution that we've been thinking that we've had as a core concept for about two years. But the basic principle, it's been called different names, like they're slasher, now we call them dunkles. And there's a reason for calling them dunkles that I won't go into. The general principle is, if you make a block and if you make a block that doesn't make it into the main chain, then instead of being rewarded, you actually get penalized. You lose an amount of ether equal to the block reward. Now, what does this do to the incentive structure? Well, it does this. Actually, this is slightly wrong, that the green thing should actually see is 0.9 minus 0.1 equals 0.8, but it's still the winner. The point is, if you look on the third one on B, vote on B, there's a 10% chance B is the right chain is gonna win and you've got your block. There's a 90% chance A is gonna win, and so the fact that you made a block on the other chain actually means that you get penalized and it hurts you. So unless you think that a chain is going to win, you actually have the incentive not to create blocks on it. If you think a chain is gonna win, you do have the incentive to create blocks on it. So the consensus game is convergent. So this is the basic kind of principle. Now, let's talk about finality. So there's CAP theorem. So Vlad talked about FLP impossibility, which is the Floyd Lynch Patterson result as opposed to FTL impossibility, which says you can't travel faster than light. That was a joke. I'm gonna talk about the CAP theorem. So basically the CAP theorem says in the event of a network partition, you can either have a consistency or you can have availability, but not both. Now if you wanna understand the CAP theorem like one of the simplest ways is to just look at the sketch proof. So it basically says if you have a decentralized network, then if the network splits in half, we're gonna send transaction A, which sends 10 ether from me to Vlad on the left half. And on the right half, I'm gonna send the same 10 ether from me over to Ming. Now, let's say there's two possibilities. One of them is on the left half, my transaction to Vlad is accepted. On the right half, my transaction to Ming is accepted. That's called inconsistency because now you have two parts of the network that believe different things. The second possibility though is at least one of those transactions is blocked. So at least one of them just doesn't go through. Now this is called being unavailable because basically try to send a transaction, it doesn't go in, the network is, or the protocol is unavailable to you. So now proof of work is availability favoring. If there is a partition, it favors availability. Most traditional Byzantine fault tolerance algorithms are consistency favoring. If the network splits in half, unless one of the halves is like more than twice as big as the other half, in which case it's not really a half, it's basically the thing just stops. In our case, we have a kind of availability favoring base layer. So like the concept of this sort of proof of stake chain that kind of looks roughly like that, this sort of base layer proof of stake chain is availability favoring. If 90% of the nodes go offline, the other 10% will carry it on. But we have this notion of a finality gadget. And the finality gadget is consistency favoring. So basically what the finality gadget does is it tries to kind of get stronger confirmations on particular blocks from inside of the protocol. So how do we do this? So one of the principles is a sort of fork-trace rule. So in proof of work, we talk about the blockchain that has the most work, proof of work backing it sort of winning. Longest chain wins, chain with the most proof of work wins. In Casper, what we talk about is the blockchain with the most value out loss backing it wins. So the blockchain where people stake sort of the most ether behind it wins. How do you stake ether behind a blockchain? Now one of them is by making a block in it. If you make a block in a blockchain, then basically you stake your ether behind that blockchain because in every blockchain other than that blockchain, you lose one block reward worth of ether. So if the block reward is 0.2 ether, you make a block on chain A, you have actually stake 0.2 ether on chain A. Now guess what we do? Basically we let people stake even more ether. So we have a separate mechanism that basically gives people the opportunity to make what we call finality claims. So in this case, you have a finality claim that says this block has some particular hash with probability 99.9%. Now what does this mean to you as a validator in practice? It means in all histories where this is the case, you get a reward of one. In all histories where this is not the case, you lose a thousand. Now of course, it's sort of easy to mathematically see you only have the incentive to do this if you actually believe this block will have this hash with 99.9% probability. So now basically, bets start off sort of being very conservative. So let's say a finality cycle begins for some block. Validators start off making sort of very low odds bets. They might say, oh, this thing's gonna be finalized with odds four to one, five to one, six to one, 10 to one. Then over time, as validators see that everyone else is betting, let's say 10 to one on a particular block, they're gonna be willing to bet 20 to one. Once everyone sees that everyone else is betting 20 to one, they're gonna be willing to bet 40 to one, and so forth. And the third of hope is that value at loss on a particular block will increase exponentially. And eventually it's gonna hit what I call economic finality. And economic finality basically means validators make these bets to such an extent that they're willing to lose all of their ether in all histories, except for those histories that contain a particular block. Why do they do this? Because in the histories that do have that particular block, they get some medium-sized reward. So over here, sort of the right side of the chart, you see there's a medium-sized reward and there's a pretty huge loss. But if you really are that sure about the block, then you'll take it. So that's, then if one particular block gets finalized, then the finality cycle sort of starts again. So why finality? Basically because it makes even forks and rollbacks that are backed by 51% validator collusions so expensive as to be impractical. Once a block is finalized, it can't be reverted. Like even if two-thirds of the validators are evil, like they can still do quite a few mean things, but they can't revert the block. And this is a really nice property to have. Another nice property to have is it really benefits like client sinking because when a single claim, when a single cryptographically signed claim represents a million, basically like a million dollars worth of value at loss on a particular block, then it's actually very easy for white clients to sort of like verify that a particular block is correct because all they do is they download a bunch of these claims and they see, oh look, people are betting $12 million that this block is correct. So I'm just gonna assume it's correct. I'm gonna then, I assume it's correct, then I download the new state and then I see what blocks in the future people are betting another $12 million on and so forth and so forth. So, sharding. So all that I've talked about so far is non-sharded, not particularly scale, while sort of simple proof of stake that can basically keeps everything fairly similar to proof of work, except it makes walk times a bit faster, it makes the system more efficient. It means the amount of ether that has to be issued in order to pay for miners goes down a lot and so forth. Sharding. So the dream basically is to achieve on-chain scaling to tens of thousands of transactions a second, but at the, through a fully decentralized peer-to-peer network that can, if needed, run on nothing but consumer laptops. Sounds like a contradiction. How do you do it? Answer is every node in the network only keeps track of a small portion of transactions, but it can use more co-proofs to verify everything if needed. Now BitTorrent scales like this. With BitTorrent, it has huge petabytes of data, but somehow it's still a decentralized network and the answer is because this happens because it's totally stores a tiny portion of the data. So basically we wanna do this for blockchains as well. The challenge of doing it in blockchain land is that you also want to make sure that on top of all this you still have a robust consensus. So sharding, basically the idea is that instead of having just one shard, you would have multiple shards and these multiple shards are kind of sort of mini blockchains that sort of grow in parallel and these shards also talk to each other. So there's sort of one shard called the home shard and on the home shard you store the validator set and that's sort of the shard that still kind of works as before. All the other shards at any particular point in time you only have about, you randomly select or pseudo randomly select 100 validators to validate that shard at any particular point in time. So during each epoch, at the start of an epoch you say you choose for each shard, pseudo randomly, these 100 validators are validate shard one, these 100 are validate shard two, these 100 are validate shard three and so forth. Why do we do this? Well number one because if the random sampling works well then it means the mechanism can be secure. Reason is if you're an attacker you can't choose which shard you're gonna validate on. So an attacker will still need to take over the majority of the entire, of close to the majority of the entire network to take over even one shard. So this is sort of the basic principle. If you want to find out more, read the MOF paper which will be over really soon and we have a proof of concept not for sharding but at least sort of for a lot of the earlier proof of stake things and you can feel free to play with it yourself. So thank you. Thank you.