Latest on Ethereum by Vitalik Buterin (Devcon4)

[Applause] okay hello everyone how are you happy anniversary of the satoshis white paper ten years yeah they are 10 in binary counting okay so today I'm going to basically talk about a ton of a theory I'm 2.0 but I'm not just from a technical point of view but more from the point of view of why aetherium 2.0 what is a theorem 2.0 and kind of how we got here right so what is a theorem 2.0 first of all if the arrium 2.

0 is this kind of combination of a bunch of different features that we've been talking about for several years researching for several years actively building for several years that are finally going to come together into this one coherent whole and these features include proof of stake Kaspar scalability sharding virtual machine improvements awasum improvements to cross channel contract logic improvements the protocol economics and so really the list goes on and on and there is some power law distribution so lots of great stuff now how did we get here right so the road to proof of stake actually started way back in 2014 with this blog post that I published in January describing this algorithm called slasher which was introduced kind of the really most basic concept and a lot of proof of steak algorithms which is this idea that if you get caught doing something wrong then this can be proven and you can be penalized for it and this how this can be used to increase security but at the time as you can see from the slide I believe that quote Salah sure is a useful construct to have in our war chest in case proof of steak mining becomes substantially more popular or a compelling reason to switch but we're not doing that yet so at the time it was not even clear yet that of steak is even the direction that we're going but as we know now over time that changed quite a lot so what happened in 2014 so first of all went through a bunch of kind of interesting and aborted ideas proof of proof of work was this kind of suggestion to try to improve scalability hub-and-spoke chains so basically you kind of have one chain in the middle and a bunch of chains on the edges um this was a kind of very early scalability and sharding proposal that tried to improve scalability for local transactions but not for transactions that are global so not for transactions that jump from one car to another hypercubes so basically except the cube should have twelve dimensions instead of three so we can get more scale even more scalability with hubs and spokes by going with hyper cubes now unfortunately for various reasons the sides he ended up getting abandoned but someone else has a big ICO to make it work so happy someone's trying it out so in 2014 there was still some progress right so there was this concept of weak subjectivity that we came up with which was this kind of semi formal security model that tries to capture the idea of kind of under what conditions are proof of stake deposits and slashing and all of these concepts actually secure also I know we got more and more certain that algorithms which much with much stronger properties than the proof of stake algorithms that existed at the time so things like pure coin and all of its derivatives were actually possible and kind of growing understanding that there was some kind of proof of state scalability strategy that you could somehow do is through random sampling but we had no idea how and we had a road map so there was this nice blog post from Vinay grouped in March 2015 where he outlines the four big stages of a theorems roadmap at the time Stage one frontier if you REM launchings yay Stage two Homestead which is kind of going from alpha to beta stage three metropolis which at the time was supposed to be about Myst and user interfaces and improving user experience but since then the focus has kind of switched more to and if enabling strong cryptography but interface work is skillful going forward in parallel and stage for serenity proof of stake right so from now on we're not going to call it a theorem 2.0 I also refuse to use the word chaste because I find an insanely lame we'll call it serenity so after this came a bit of a winter so we had a bunch of different kind of abortive attempts at solving some of the core problems and proof of steak some of the core problems and scalability research on Casper quietly began Vlad kind of quietly began to hang all of his work on Casper CBC one of the first interesting ideas was this kind of idea of consensus by bet where basically people would kind of bet on which block becomes finalized next and then once more people bet on a block that itself becomes information that gets fed into other people's bets and so the idea is that you would have this kind of recursive formula or and more and more people would bet more and more strongly on a block at a on a block over time and after a logarithmic number of rounds everyone would be betting their entire money on a block and that would be called finality that so we actually took this idea really far we created an entire proof of concept for it and you could see it finalizing you can see here is a signature function I mean burns most of our time on this but then that in whole idea kind of ended up going away basically once we realized how to make kind of proper BFT inspired consensus actually work sanely um rent so this is the idea that instead of charging a big one-time fee for filling storage we would kind of charge fees over time so basically for every day or every block or whatever that some storage slot is filled you would have to kind of pay some amount of ether for it there was this one I'm ap number number 35 that I tried to call EAP 103 but really it was a IP number 35 because that was the issue number that takes precedence and this was one of the really early ideas are trying to kind of formalize this concept and we've had many iterations on the idea of how to implement can rent maximally nicely since then there was also this scalability paper that we tried to do back in 2015 and this tried to kind of formalize the idea of kind of quadratic sharding super quadratic sharding but it was very complicated it had these kind of very complicated escalation games it had the a lot of them were kind of inspired by ideas of how escalation works in court systems an analogy that I know Joseph with philosopher Roy lobster Hughes as well but we tried to use it for the base layer deep state reversions so basically if something goes wrong then potentially large portions of the state could and if get reverted even fairly far into the future so there was a bunch of complexity right now one of the fundamental problems that we couldn't quite capture but that we were kind of event slowly inching towards was this idea of the fisherman's dilemma and this is a fundamentally and very fundamental concept in shorting research that basically describes the big difference between scaling execution of state and scale and execution of programs versus scaling availability of data and the problem basically is that with an execution of programs you can have people commit to what the answer is and you can later kind of play a game and try it's a kind of binary search your weights or who actually made a mistake and you can he knows everyone who made a mistake after the fact the problem with data availability is that whatever the game is you can cheat the game because you can just not publish the any data at all until the mechanism tries to check if you published it and only then do you publish just the data that the mechanism checked for and this turns out to be a fairly large flaw in a fairly large class of the scalability algorithms and I wrote this a blog post if you want to search for it you can call it it's called a note on a racial coding and data availability that describes some of the issues and more deets but still this was one of the things that delayed us but even still we were happily making progress aetherium was moving forward we were on our way wait then this happened okay no more problems oh wait then this happened so the dow hack the daus attacks all of that ended up delaying a lot of people's time and attention by potentially up to six months but even still work move forward he wasa moved forward the work on the virtual machine moved forward and work on the end of alternatives things like EVM 1.5 moved forward and people were still continuing to kind of get a better and better idea of look basically what a more optimal blockchain Algar from many different angles so after this that we started making huge progress and very quickly right so during all of this time there were these different strands of research that we're going on some of them around proof of stake and trying to do base layer consensus more efficiently some of them were around scalability in trying a shard base layer consensus some of them were around improving the efficiency of the virtual machine some of them were around things like abstraction that would allow people to use whatever signature algorithms they wanted for their accounts which could provide post quantum security it would make it easier to make privacy solutions among a bunch of other benefits protocol economic improvements and really all these things were still happening all the way through so at some point around the beginning of 2017 we finally came up with this con the sum protocol that we gave this very kind of unambitious name of a minimal swashing conditions and minimal swashy conditions was basically a kind of translation of pbft style traditional Byzantine consensus so the same sort of stuff that was agreed on by a lamp or work wench stockmeyer and all those fate and all those wonderful people back in the 1980s but sim flying it and kind of carrying it for forward into more of a blockchain context right so the idea basically basically is that in a blockchain you just keep on having these new blocks appear over time and you can gain these nice kind of pipelining efficiencies by merging sequence numbers and viewers every time a new round starts you would add new data into the round you can also have the second kind of round of confirmation for one piece of data be the first round of confirmation for the next piece of data and you can really kind of get experiment amount of efficiency and out of all of that so the first part was step was minimal swashing additions which had six /e conditions then it went down to four and finally about half a year later we ended up merging prepares that commits and this gave us Casper the Friendly finality gadget Casper FFG so last year at Def Con I presented this new shorting design that basically kept the main chain and then creed did sharding as a kind of way all kind of layer two system on top of the existing main chain that would then kind of get upgraded to being the layer one once it gets solid enough from Vlad the Casper CBC paper the Casper FFG proof of concept so December 31st 2017 2340 bangkok time because we happen to be in thailand at the time basically what happens here is we pretty much managed to nail down what the spec of a version of hybrid proof of stake would look like and this version of hybrid proof of stake would basically use the ideas from Casper FFG use these a kind of traditional Byzantine fault tolerant consensus inspired ideas of how to do proof of stake on top of the existing proof of work chain so this would be a mechanism that would allow us to get to hybrid proof of stake fairly quickly with actually a fairly minimal level of disruption to the existing blockchain and then the theory is that we would be able to upgrade to full proof of stake over time and we got very far in this direction and there was a test that there were Python clients there there were messages going between different VPSs and different servers and different computers and it got very far and at the same time we were making a lot of progress on sharding so we Hakeem continued working on the shortening SPAC eventually we had this retreat in Taipei in March and around here a lot of the ideas around how to implement he shorted blockchain seemed seems to solidify seemed to solidify so in June we made this kind of very difficult but I think in the long term really very beneficial and valuable decision which is that we said that hey over here we have a bunch of teams that are trying to implement hybrid proof of stake and they're trying to do the do the Kasper FFG thing build the Kasper effigy implementation as a smart contract inside of the existing blockchain make a few tweaks to the fortress rule then over here we had a completely separate group that was trying to make a sharding system that was trying to make a validate or manager contract so that was later renamed into a shorting manager contract on the main chain and that was trying to build a shorting system on top of that these groups were kind of not talking to each other too much then on the shorting side it eventually became clear that we would get much more efficiency by making the kind of core of the shorting system not be a contract on the proof of work chain but instead be its own proof of stake chain and because that way we could make validation much more efficient we did not have to deal with EVM overhead we did not have to deal with gas we would not have to deal with unpredictable proof of work block times we can make block times faster along with a whole bunch of other efficiencies and we realized hey we're working on proof of stake here we're working on proof of stake here why are we doing two separate proof of stake things again and so we decided to just merge the two together this did end up kind of nullifying a lot of work that came for but what it meant is that instead of have it working on these two separate implementations we were working together on this one spec this one protocol that would get us the benefits of Casper proof of stake and sharding essentially at the same time right so basically instead of trying to go to go to I go to one destination then go to another destination then later on have the Miss massive work of figuring out how to merge the two we would just take a path which would take a little longer at the beginning but the place that it gets to actually is a proof of stake and sharded blockchain with the properties that we were looking for so in the meantime we spent a lot of time arguing about fork choice rules B's we ended up kind of getting closer and closer and deeper into realizing that fortress rules based on ghost the agree D heaviest observed sub-tree algorithm that was originally intended for proof of work but repurposed by us for proof of stake made a huge amount of sense we were Justin started doing research on verifiable delay functions we had this workshop at Stanford and we made a lot of progress on verifiable to wave functions there and justin is still collaborating with a lot of researchers from there more ideas on how to do abstraction how to do this idea where individual users can choose their own signature algorithms for their accounts more ideas on rent which we decided to rename to storage maintenance fees for political reasons and research so there's a lot of work on cross shore transactions so for example there is this a post I made on cross shard contract yanking which kind of generalizes the traditional distributed systems concept of walking into something that makes sense in this kind of asynchronous to cross short context also wrote this paper on resource pricing which includes ideas about a kind of optimized and my ends up much more fish Phee market along with storage how to do storage maintenance fees and why and the different trade-offs between different ways of setting them and I mean Casey here a de trio wrote this post on doing synchronous squash across chart transactions so and of course in the meantime Kasper CBC research also expanded into and if Kasper CBC is own brand of sharding which is totally not called vlaardingen opswat Lee hates that term so development right so be there's one of the kind of key strategies that we tried to really push forward in the etherium 2.0 path is the idea of creative multi-client decentralized development and this wasn't just a kind of because we have an ideological belief in decentralization this was also a kind of very pragmatic strategy to not basically had your bet first of all hedge your bets against the possibility that any one software development team would not perform well second because we already we have plenty of experience from the shanghai das attacks of how you know there are many of cases where if one client has a bug having other clients being available allows the network to continue running better also wanting to kind of make the development ecosystem less dependent on the foundation itself so the client that the etherion foundation works on is I'm actually the Python client and so it's in it has plenty of use cases but in Python just as a language has inherent performance limitations and so there's always going to be an incentive to try running the stuff built by the wonderful folks at prismatic and white house and status and Pegasus and all the other teams that are popping popping up seemingly every month so soon something which is totally not going to be called Jasper serenity begins yay [Applause] right so what is serenity right so first of all it's the fourth stage after frontier and homestead and metropolis and where metropolis is broken down into Byzantium in Constantinople with Constantinople coming very soon as well and that's um a realization of all of these different strands of research that we have been spending all of our time on for the last four years right so this includes Caspar and not just hybrid Caspar 100% organic genuine pure Caspar sharding awasum and all of these other prong of protocol research ideas this is a new blockchain for in the sense of being a data structure but it has this kind of link to the existing proof of work chain right so we be able to like the proof of stake chain would be aware of the block cassius of the proof of work chain you would be able to move ether from the proof of work chain into the into the proof of stake chain so it's a new system but it's a connected system and the kind of long long-term goal is that once this new system is stable enough then basically all of the applications on the existing blockchain can be sort of folded into a contract on one shard of the new system that would kind of be an EVM interpreter written in e wasum and not finalized but this seems to kind of roughly be where the road map is going at this point serenity is also the world computer at its really as it's really meant to be not a smartphone from 1999 that can process 15 transactions per second and maybe potentially play snake and it's totally centralized and we hope that on in many metrics that can be even more decentralized than today so for example as a beacon chain validator your storage requirements at this point seem like they will be under one gigabyte as compared to like something like 8 gigabytes of state storage today and the 1.8 terabytes that trolls on the internet seems to thank the ethereum blockchain require for some stupid reason expected phases so phase zero beacon chain proof of stake and beacon chain proof of stake is actually it's kind of the blockchain stock kind of hold any information right it's kind of like a dummy chain so all that you have is you have validators and these validators are executing and they're running the proof of stake algorithm so this is kind of like halfway between a test at anim net it's not quite a test net because you would be able to actually stake real ether and earn real rewards on it but it's also not quite a main net because it doesn't have applications and so if it breaks people are hopefully not going to cry too badly yes they were as they did when the shanghai das attacks made everyone's ICS go slowly phase one shards as data chains so basically the idea here is that this is where they're kind of shorting part turns on right so here it's just it's a kind of simplified version that doesn't do shorting of state it does shorting of data so you can throw data on the chain you could try to make just do a state execution engine yourself but really the simplest thing to use it for is data and so if you wants to do decentralized weather on a blockchain you'll now have the scalability to do this but you won't really have the kind of all of the state execution capability to build you know it's smart contract applications and all of the really fancy complex stuff stays to enable state transitions and this includes enabling the virtual machine enabling accounts contracts ether ether moving between shards all of this cool stuff and phase three and beyond iterate improve add technology so expected features pure proof of stake faster times a synchronous confirmation so about 8 to 16 seconds now notice that because of how the fork choice rule and the Outlands the signing mechanism works in the beacon chain one confirmation in the beacon chain involves messages from hundreds of validators and so for all probabilistic points of view it's actually equivalence to hundreds of confirmations of say the etherium fortune right so you under a synchronous model you should be able to treat one block as being close to final economic finality and safety under a synchrony comes after ten to twenty minutes and fast virtual machine execution via awasum and hopefully a thousand times higher scalability we will see post serenity innovation improvements in privacy in perso there has already been a lot of work done so for example in Byzantium we activated the pre compiles for elliptic curve operations an elliptic curve pairings and Barry White has been doing great work on building layer 2 solutions to preserve privacy of coin transfers voting reputation systems and all of this work could be carried over cross our transactions semi private chains so the idea here is that if he wants to build some application where the data is kept private between a few users you could still dump all the data on the public chain but you would just dump it in an encrypted form or you can dump hashes of it and you zero knowledge proof select your choice proof of stake improvements there's definitely a place in our heart and the roadmaps heart for Kasper CBC when it becomes it becomes clear that it's that there is a kind of a version that makes sense from an overhead point of view post serenity innovation so at some points we have all what we wants you and we had you have a door open to kind of upgrade everything that starts so using Starks for signature aggregation for verifying erasure codes for data availability checks maybe eventually for checking correctness of state execution maybe stronger forms of cross shore transactions faster single confirmations getting the confirmation time down from 8 seconds even lower medium-term goals eventually stabilize at least the kind of functionality of layer 1 think about issuance think about fees agree more and more over time on kind of what specific guarantees people expect from the protocol and things that people expect as features for the protocols for a long time think about governance now what's next immediately so what happens before kind of the big launch well first of all stabilizing the protocols back so for those who have been watching github.

com slash aetherium slash eath - 2.0 or sorry if 2.0 - backslash dream master specs beacon chain md something like that this spec has been kind of moving fairly quickly fairly quickly but you know it will stabilize fairly soon continue development and testing there's something like eight implementations of the etherium 2.0 protocol happening now cross clients test that so I believe a free the madest made a statement idea he hopes to see you cross client work like really picking up in q1 next year I mean we'll see that would be definitely nice to see a kind of test networking between to implementation in August move gonna be nice to see a test networking between one implementation like really like so as I kind of quick hysteria aside rightly iam aetherium 1.0 development time between conception of the white paper and launch nineteen months part of the reason why it took so long is because we tried to get kind of cross clients compatibility way before the spec even finished and so we had to agree test release test net a weight protocol changes agree test release it says that await more protocol changes and we had about five cycles of this this time around we have the luxury of kind of learning from that lesson and we don't really need to kind of focus on cross client compatibility until we have something close to a release King a release candidates of the spec but I think we're actually not that far from a release candidate of the spec at least for kind of limited portions that don't that don't include a state execution so we'll see security audits who here thinks security audits are important who here thinks security audits are not important who's here thinks the world is a literally controlled by Lizardman okay that's okay so more people from the third of the second that's good to hear and then what's words on that launch uh who here thinks launching is not important okay um who here fix like your favorite political candidate is literally a lizard man okay so launch there we go I mean that's basically you know the milestone that we've all been waiting for that we've been working toward for the last five four to five years and a milestone which is really no longer so far away so thank you what oh sorry okay enjoy [Applause] you