# Eth 2.0 tldr by Danny Ryan (Devcon5)

- Speakers: [Danny Ryan](https://streameth.org/speakers/danny-ryan)
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2020-10-07
- Duration: 19:53
- Watch: https://streameth.org/watch/yt-x7vAU5zEIzU
- YouTube: https://www.youtube.com/watch?v=x7vAU5zEIzU

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/5/eth-20-tldr

High level overview of the work that has gone into Ethereum 2.0 since last devcon, the major milestones achieved, the landscape of research, and where we're going in the next 12 months. This serves as an overview talk for the track to get devcon attendees acquainted with the space in general and ground them for the range of more technical talks throughout the conference.

Speaker(s): Danny Ryan
Skill level: Intermediate
Track: Consensus layer
Keywords: eth2, updates, technical

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 5 was held in Osaka, Japan on Oct 8 - 11, 2019.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

I'm Danny Ryan I work with the etherion foundation on the research team I do a lot of work on e to specs research coordination of client development and all sorts of fun stuff today give you an update on what's going on because there's a lot going on it's kind of hard to keep up with and hopefully also help give you the lay of the land and also help you become acquainted with some of the fun and interesting talks that are gonna happen over the next few days so a lots going on but first I always like to talk about the architecture of e to the simple single blockchain of it there in one so it's not very simple but a lot of us have a good intuition for it and I hope that we can carry a good model mental model of the intuition of e - moving forward so we divided production in implementation of this in two phases the initial phase phase zero called the beacon chain is a pure proof of stake blockchain that uses kasparov of G as its core consensus and builds blocks has validators and it has this loose tie to the existing theorem one chain to handle deposits there's a couple of rolls of validators do on this chain they build blocks but just as importantly if not more importantly they attest to blocks so every epoch or unit of time validators are called upon to vote on what they see is the head of the chain to give weight to the fork choice and don't allow a small minority of proposers to take over the chain so that's phase zero it is a simple proof of stake chain it doesn't do that much but it is the core infrastructure that upon which we build additional phases phase one we have the shard chains the shard chains ask data and I'll talk about that nuance in a second so instead of just the beacon chain being built we have these other shard chains being built in parallel these shard chains are also cross-linked back into the beacon chain and when this happens it serves a few purposes one it routes the fork choice of the shard chain into the beacon chain which should be kind of canonical a canonical reference it also serves these points of cross links serve as the point for asynchronous communication between shard chains so with phase two we've take this take the shard at infrastructure and we actually add state and execution and a layer one interpretation of shard chains and data and I'll get in a little bit more into what that means a little further down the line so in theorem two it's not that complicated and the next phase part of phase two would be to get rid of the work chain role each one into eath to which we can talk about a little bit later so theorem two sometimes I think about it abstractly it's kind of like a concrete object that we're building in an abstract void of space sometimes I think about sometimes like these like massive space habitats and this Stanford torus is particularly apt because you have this like core central component to the space habitat that serves as the infrastructure the energy generation where light is refracted into the outer torus which is where the actual people live the user level activity and so to build this thing sanely you can't just like build the whole thing on earth because it's too big you have to build it in space and you obviously start is this core system this core like central infrastructure building it out until we finally have paradise user activity so those are the phases of v2 so what's been going on with specs and research we froze the spec July first phase zero of the spec that is and today later today we're doing a deep dive on this spec it should be a good time I think it's an hour workshop digging into that this point really marks the transition towards production for client and implementation teams I finally gave them something very stable to work towards and and I'll give you an update on their progress soon a lot of consensus tests hand written tests that help us make sure that clients come to consensus with each other before we actually get to production the networks shout out to proto lambda he did a lot of work on this and has saved us huge huge headache debugging things on instance on networks been a lot of work on efficient merkel proofs we have these pretty cool tree structure called simple serialize tree hashing which allows us to take generally objects and fit them into Merkle trees and so we've been working on how to efficiently make proofs about these which will be relevant to execution environment state execution needs to and like clients and all sorts of other cool things a lot of works been going on to decentralize staking pools this is kind of a little-known component of the protocol but all of the different things that a validator must do their duties we've been designing in a way that is multi-party computation friendly and there's a talk later today on that about decentralized taking pools if this is this is kind of a little-known area so go to that talk check it out and and some of y'all should probably start building these multi-party all things there's been a lot of academic analysis audits and formal verification I want to thank you on Zang who's been doing a lot of work on formalizing Kasper F of G in this new context of proof of stake a lot of audits been going on and runtime verifications been doing some great formal verification work both in the deposit contract and recently created a model of the KB contain a formal model in which we plan on verifying properties of the protocol such as safety aliveness and other other things there's a short talk during the climate summit tomorrow if you want to hear more about the KP keychain networking spec out a lot of love recently it kind of existed in just a proto form until a few months ago shout out to Nimbus lighthouse and protocol labs remembers that those team stepped up and helped drive this which was critical to getting initial Interop of our clients working and I do just want a quick side Ghaleb p2p there's been a lot of quite frankly food around the p2p weather it's sudo a suitable choice and as teams have been taking more ownership over this over their domains of this project and finally integrating them in we've had a great success and are excited to continue to use it phase one speck Justin Drake's given this thing a lot of love recently it's now quite frankly pretty elegant mirrors the phase zero specification a lot of work on testing ironing out some of the more nuanced details and exploring some opportunities to maybe increase the amount of cross-linking that happens to help facilitate crush our communication so something that's in the past six months the lay of the land in the direction of what we call phase two which is that state and execution of eath to has radically changed and actually it's not state an execution it's stateless execution KC from the e azam team put out a post in April about using kind of reframing how we think about this highly scalable system so at its core what e2 does is it solves data availability and it's a date availability engine that comes to consensus on anywhere between like one and ten megabytes of data per second and so reframing the phase two conversation around how we can more abstractly just use this highly scalable data layer instead of having to bake all of the execution and things into layer one now what does that actually mean state an execution an eighth one this is very limited view of over the world there but in in consensus we have this strong notion of state you assume when you're processing a block that you have access to all state and you also have a strong embedded execution engine where we have these formal and hard-coded rules and notions of account and account model and so your changes has transaction data and execute using these rules upon that state transitioning that state within the consensus but in e2 we're moving to a more abstracted model where instead of having the heart could its State execution rules and having the entirety of state available within the consensus removing to this abstracted model which we call execution environments or E's in which state the the notion of state the notion of account and the notion of execution upon that can be defined in a more abstract way and can be defined actually not in the core consensus but at the user level and so we have these at each of these is an execution environment which is a chunk of code wasum code which would specify the rules of execution within that realm within that domain and you can actually deploy more of these the actual model on the cost of either burning or locking capitols deploy these is still up for debate but it would be expensive because you're deploying code on this globally accessible thing called the beacon chain and so where's the state the state does not exist in the consensus the state actually exists the state that you need to operate blocks which these blocks you know are a little bit fatter than previous because now instead of just transaction user level data we have what we call witnesses which are the components of state required to operate on that block so it's kind of like a the database and proofs that that data is valid against the state route and so when you update a block you're actually not modifying the state within the consensus you're just updating the state route which is kind of like the digests of the state you can do a lot of really cool and interesting things here and from my perspective and what this allows us to do is instead of us guessing what aetherium can or should be in 20 30 years this allows us to like naturally extend and upgrade and modify execution as there's innovations on that layer and the really nice thing is that it gives us a clear trajectory and model on how eath one can actually be slotted into eath 2 and has given us more of a concrete idea of how to handle create and trajectory so eath one actually can become one of these execution environments where essentially the EVM interpreter written as wasum can become the exec code within this execution environment and the state route the existing current state route within eath one would be forked in here along with the ether balances there's a lot of work going on on evaluating evaluating stateless execution trying to understand and capture the complexity of each one as an ee and there's a there's a workshop I think it's a couple of walls and workshops in the last day there's a fishbowl conversation about all of this so check it out cool a lot of work going on a light clients we have a super light sync protocol on the order overhead of Bitcoin SP been a lot of work on incentivized servers Zolt is giving a talk soon after this about that starting now let's starts been digging into it and there's a lot of le s work that will inform he's to learn more there's some talks the client journey a lot has transpired in the past year we've gone around son once and clients have also gone from early legend prototypes into what are beginning to look like production grade systems the journey was as you if you've been following it was difficult for a while because they were beginning to work as we were still writing specifications but as I said we've definitely moved into that production engineering phase for phase zero something particularly exciting that happened recently was interrupt Thank You Joseph DeLong and consensus for putting this on at the time when they came up with the idea I was a little skeptical it sounded a little bit crazy and I wasn't sure if it was going to actually be a good use of our time by day two we were quite ecstatic about being all together and getting things to Interop because we were making incredible progress so I think all seven clients that showed up successfully interrupts I think that's actually five of them right there and parody Jasper which could not be in attendance has also begun to work through some of these exercises beyond that discussions on sink and ironing out other cornets of the protocol fun little side projects I think we had a test net with 2000 validators on a few different machines which was particularly exciting so some initial load testing and this was a fun one this is a couple raspberry PI's on a small network with deacon chains running on them mommy later today I think on this stage is giving a talk about the Raspberry Pi it should be a pretty fun one it's about like the load of eath - and the expected requirements and actually getting it to run and build on these small devices so what is coming up for clients optimizations so one of the I think probably the the most obvious place for optimizations is first BLS signature processing we process a lot of signatures we have a lot of validators and even though we can aggregate these signatures that's still a high source of load so we've seen people begin to open up the BLS implementations and optimize optimize them seeing some gains order of magnitude gains there what else the tree hashing structure we have a lot of hashing that goes on and if you do it naively it takes an incredible amount of load but fortunately much of the tree doesn't change this is a lot of caching optimizations going on stabilized we need to bring these things towards production stability and grade such that they can run essentially forever unstopped and usability eyes that's not a word but the usability UX getting these hands getting these things in the hands of users and making them actual products is instead of command-line tools that someone that built them can sophisticatedly use more usable and real products there's good some people are actually doing some independent work on validator clients right now to actually like make nice buoys and there's some promising things in that respect this guy right so we're also doing some fuzzing efforts guido recently a while built out kind of a core infrastructure for handling differentials buzzing of clients and recently mehdi from lighthouse has taken over that integrated a couple clients in and it's figuring out how to randomly throw all sorts of junk at these clients to see that they all handle these crazy inputs the same what this does is it takes we have our consensus tests where all the all the scenarios that we could think of but fortunately with randomization we can come up with all sorts scenarios that we didn't think of and find the edge cases before production so what's next as i mentioned we're moving we're in that production phase we're removing phase zero towards production a lot of the conversation since Interop has been about continued test nuts so both private doing some private load tests on clients but also opening up towards public test nuts and incentivize test nuts so keep your eyes peeled for that if you're thinking about being a validator this is your handi your chance to get your hands dirty and be in an active when these public test sets come out be an active participant if it doesn't work tell somebody if it's hard to install file an issue like if you have an idea for increasing the usability either open up an issue suggesting it or go and fix it so this is definitely an exciting time this this last mile getting these things to production so be active and be engaged with it phase one and two rd the specs for phase one are coming i mean they're they're they're in a place in which people are prototyping props the quilt team yesterday they did a demo of phase one and a minimal phase two built on top of lighthouse and beyond that a lot of work going on just kind of refining this idea of execution environments it's quite a blind a large design space so we're trying to hone that in the coming months developer tooling and dialogue so as Casey from wasman likes to say this this needs to be a humanistic humanist process a human focused process the reason that aetherium is so great is the developer's unity that we have out here and so making sure that the transition from eighth one to eath two enables and enhances the experience of developers is very important if this goes according to plan we can kind of rewire and rework some of the interfaces and things the things behind and underneath our current tools and developer interfaces such that developers can continue using the things that they use to continue building on ethereum and making it great here's a quick glance at you to track i'm sure you have it in your hat but there's a quick view if you want it lots of fun stuff putting it to to work that should be fun checking out how we can use finality on eighth one to enhance the security all sorts of stuff check it out I'll be at the phase zero deep dive today we'll be digging into I know I like we do this high-level thing where we just show it all where I kind of go through it very simply but we're gonna dig into the different components and help you read and understand the specs today I want to highlight the two Oh client summit which is tomorrow we have a number of clients working on this problem as you're aware and they're going to be doing these like twelve to fifteen minute talks discussing different components of the design different challenges at hand and after that there'll be a panel talking about upcoming tests nuts challenges etc it's all I got for you today build in the future thanks for having me [Applause] you