The Mauve Revolution

[Music] so you say you want a a revolution how about a mauve Revolution metallic cool yay okay um where is the clicky thing oh there it is perfect so in the uh wait how does this even work in the interest of press I'll get right to the point so well okay maybe I won't get right to the point where is the clicker so well first what people read the comic that the that the mo paper is named after although I'm sure lots of you have already seen it which color you want the blockchain I think move has the most Ram so let's scale the blockchain let's add some more RAM let's make the blockchain mo so ethereum is obviously a complet a table system it's uh as uh 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 uh a uh payment is uh when a payment normally takes seconds to block is minutes away very little privacy at based 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 the thean platform falls short and seeing if we what parts of this we can improve so there's different parts to this problem so privacy zuku made this 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 um scale 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 smaller problems that we have to worry about mining centralization selfish mining vulnerabilities interfaces unclean 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 $ th000 to buy a minor you take your minor plug it into the internet plug it into electricity and your minor has the ability to stochastically generate blocks if you have a minor of $1,000 you might produce like one block a day if you put $2,000 into your monitor you might produce two blocks a day but in 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 minor and the virtual and the uh then the pro inside of the protocol there's a rule that says if you have a virtual minor you have the ability to stochastically generate blocks so the protocol itself basically defines you it gives you the right to create these blocks and it gives gives you the right to create these blocks in proportion to sort of how big your virtual minor is if you get a $1,000 virtual minor then you can maybe create one block a day if you have a $2,000 virtual minor 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 solves Wast the electricity problem so here's the approach that we're taking in C in at least my version of Casper so in the state there is a there is a set of 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 uh a uh State the state is the set of sort of current information that 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 blonded validators so blonded validators are kind of active participants in the protocol and uh they uh active participants in the consensus protocol now if basically the state is the set of people who have virtual minors the minors are virtual and where where exactly are these virtual miners kept track of or they 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 along with your call you send some ether in then you can become a validator so you specify a bunch of parameters validation code randale 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 2 so like between 12 and 24 hours from now your validator joins the active validator pool and at that point you basically your virtual minor is active now while a validator is inducted they will sometimes be pseudo randomly assigns 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 per to the amount of ether that You' deposited now in proof of work a block has to contain a non and that non kind of pro is a solution to a proof of work puzzle and that solution to 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 private key and it's checked against evaluator's public key but one thing that we want to do here is we want instead of having a 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 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 us a validator are concerned about let's say Quantum cryptography let's say you think that the NSA know as an arm the uh pervasive arm of the state that it is has access to quantum computers and it can break public elliptic curve signatures in an instant then you might want to switch to Lamport signatures Lamport signatures are a type of signature that's called want resistant and if you care about that then basically can you don't have to wait for the protocol to Heart Fork you can just switch to it yourself tomorrow so a validator can also call start withdrawal 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 minor and sort of turn it right back into liquid ether so it's not a oneway process if you're done mining you can call this function called start withdrawal and you withdraw and then one to two EPO later you you are no longer part of the active validator pool you can check your note off 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 withraw 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 ether out nice and simple so people according to some people there are supposed fundamental flaws in proof of stake so let me go through some of them so one of the main problem s 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 the state grunting problem basically says there may exist an economic incentive for a validator to perform computations due VAR 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 AC 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 you can manipulate your weight 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 algorith validator was suud randomly sampled based on the signature of the current block so the attack Vector there is basically to just grind a bunch of signatur until you find one that favors you in other 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 you know where that address would get assigned to 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 fixed 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 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 AV information that validators have committed toally submit the hash but the validators reveal the information while creating a block while creating their block so block n contains basically I see 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 like manipulate what your original commitments are the problem is that the 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 kind of predicting sort of 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 will 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 okay the's done go back to ethereum Classic so what we do instead is we basic instead of selecting one validator we select the sequence of validators so basically we select like an infinite sequence where if validator zero doesn't show up then say then after some point point in time validator one can create a block if validator one also is offline then validator 2 can create a block and so forth so this is actually fairly standard so like NXT works this way a lot of existing proof of stake algorithms work this way so this is not particularly novel and generally sort of is the standard way that the sort of stuff is done in my opinion there are some sort of incentive issues that remain that should be researched more regarding whether or not sort of timing is incentive compatible but in general this at least in practice this has worked fairly well so next next Point let's talk about nothing at so nothing at stake is this other reason why proof of stake is terrible and can never never work which why we should just like give up and go back to proof of work no um so basically here's here's the problem so in the normal case you have you as a minor have four choices let's say there exists a fork let's say there exist two 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 Nei 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 H because you have to actually split your work in half you get only half of one and half of the other and that 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 a sort of thing that we wants 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 votee 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 whichever one wins you profit yay so everyone actually even if there are no attackers everyone has the incentive to create a block on every single ch at the same time and therefore in an economic of 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 like as a core concept for about two years but the basic PR it's been called it's been called different names like there's slasher now we call now we call them dunal um and there's a reason for calling them dunkles that I won't go into um there the general principle is if you 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 this is slightly wrong the the the green thing should actually see 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's the right chain is going to win and you've got your block there's a 90% chance a is going that get penalized and it hurs you unless think a chain is going to win you actually have the incentive not to create blocks on it if you think a chain is going to win you have the you do have the incentive to create blocks on it so the consensus game is conent 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 um which is the Floy Lynch pattered to Ft impossibility which says you can't travel F light that was a joke I'm going to talk about the cap theorem so it 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 want to understand the capap theorem like the one of the simplest ways is to just like look at the sketch proof so it basically says if you have a decentralized network then if the network splits in half we're going to send transaction a which sends know 10 ether from me to Vlad on the left half and on the right half I'm going to 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 like just doesn't go through now this is called being unavailable because basically try to send a transaction doesn't go in the network is or the protocol is unavailable to you so our now proof of work is availability favoring if there is a partition it favors availability most traditional bantine F tolerance algorithms are consistency favoring if there 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 uh 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 uh kind of looks roughly like uh like that this sort of Bas 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 um what the finality G 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 the sort of foru rule so in proof of work we talk about the blockchain that has the most work proof of work backing it sort of winning right longest chain wins chain with the most proof of work wins in Casper what we talk about is the blockchain with the most value at loss backing it wins so the blockchain where people stake sort of the most ether behind it wins how do you stake ether behind the blockchain now one of that 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 the you lose one block reward worth of ether so if you if the block reward is 0.2 ether you make a block you make a block on chain a you have actually Stak 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 in 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 going to can be finalized with odds 4 to1 5 to1 6:1 10:1 then over time as validators see that everyone else is betting let's 10 to1 on a particular on a particular block they're going to be willing to bet 20 to1 once everyone sees that everyone else is betting 20 to1 they're going to be willing to bet 40 to1 and so forth and the third of Hope is that value at loss on a particular block will increase exponentially and eventually it's going to hit what I call economic finality and economic finality basically means validators make these bets to such an extent that they're they are willing to lose all of their ether in all all histories except for those histories that contain a particular block why do they do this because in the history in the histories that do have that particular block they get some mediumsized reward so you know over here sort of the right side of the chart you see there's a mediumsized reward and there's a pretty huge loss but if you if you really are that sure about the block then you'll take it so that's if 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 do 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 line syncing because when a single trans one a single claim when a single cryptographically signed claim represents a milon basically like a million dollar worth of value loss on a particular block then it's actually very easy for light clients to sort of light verify that a particular block is correct because all they do is they download a bunch of these of these claims and they see oh look people are betting $ 12 million that this block is correct so I'm just going to assume it's correct I'm going to then I assume it's correct then I download the new state and then I see what 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-shed 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 uh has to be issued in order to pay for miners goes down a lot and so forth Shing so the dream basically is to achieve unchain scaling to tens of thousands of transactions a second but at this 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 note in the network only keeps track of a small portion of transactions but it can it can use mer proofs to verify everything if needed now bitor scales like this with bit torent you know it has huge like pedabytes of data but somehow it's still a decentralized network and the is because each this happens because each note Only Stores a tiny portion of the of the data so basically we want to do this for blockchains as well the challenge of doing it in blockchain land is that you also wants 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 at any particular point in time you only have about you randomly select or pseudo randomly select 100 validators to be a to validate that chard at at any particular point in time so during each Epoch at you at the start of an Epoch you say you choose for each Shard Su or randomly these 100 validators are validate chart one these 100 will validate chart two these 100 will validate chart three and so forth why do we do this well number one the 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 going to you're going to 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 chard so this is sort of the basic principle um if he wants to find out more read the M paper which will be a releas soon and we have a proof of concept not for charting but at least sort of for a lot of the earlier proof things and you can feel free to pray with it yourself so thank you