Eth2.0 Update - progress, roadmap, and happenings
EDCON 2019 · 11 Apr 2019 · 19:54
Danny Ryan reviews the evolution of the Eth2 design and the planned beacon-chain, shard-data and execution phases as understood in April 2019. He explains validator duties, crosslinks and cross-shard communication, then surveys client implementations, testnets and the coordination needed to stabilize specifications.
Speakers
Topics
From EDCON 2019, hosted by EDCON.
Transcript
um so next up we have someone who over the past year has been super critical and super awesome in pushing the youth to space forward so let's give a warm welcome to Danny Ryan hello I'm Danny Ryan I work with the etherium foundation I spend almost all of my time on aetherium 2.0 research specifications some client development client coordination I run some calls I try to do everything to help just move this thing forward today I want to talk to you about the state of Ihram 2.0 we have
a number of awesome talks coming up in the next few days with some researchers at metallic started off and clients and so I want to just ground you in what the hell has been going on a little bit about the architecture and what we expect moving forward so the past 12 months quick recap so 12 months ago this project didn't exist we had two major scaling and protocol upgrade efforts happening in parallel was the hybrid Casper proof estate group of work in bedded into a contract and sharding via the sharding manager contract in which
these charred chains are kind of like bolted on to the existing system managed in a contract but these were system level contracts meaning that they're recognized by the protocol as containing information relevant to the consensus and both them were happening really in the most of the complexity was managed inside of these contracts in IBM so there were a number of a lot of progress was made and eip was written on the casper work and on a couple of clients were developing that and there were some prototypes going on with the sharding smc but we were running to some issues primarily issues by trying to build the sauna to existing system and trying to
do things doing complex things inside the UVM a lot of the issues were around trying to process a high number of signatures in the EBM which was limiting the amount of validators the group participate in these games and ultimately limiting the decentralization and scalability of the systems so we deprecated both these work streams and unified them Kaspar heart charting deprecated them into a new much more radical design that's been deemed 2.0 the ultimate vision of serenity this radical new design has allowed us to make more bold decisions we architect from the ground up and give us really a truly decentralized scalable block chain
that we've all been looking for so mid 2018 lots of research lots of design a lot of the components of the research were there but it was really this effort of kind of figuring out how everything was gonna fit together into a more concrete spec that people could begin working on a lot of work in research we had a couple of Python proof of concepts and this like hacking D proto spec if you were in a client implement at the time it was kind of a nightmare to follow the changes there as we got towards DEFCON we moved everything into a specs repo where we had changelogs client implementing teams really were ramping up at the time beginning to participate a lot more in
the conversation and build out some proto clients and we have these two o calls we had a workshop this is a picture of a workshop in Prague it was incredibly productive getting us all in the same room and super-cold we're all wearing like jackets in this warehouse is a good time prototypes for getting it happen and the bones at this point I'd say of the spec we're in place but we were still in for some major major revisions over the coming months come January 31st we had an internal deadline of having a feature complete spec release this is the first release the January pre-release of the phase zero spec and I'll go into a little bit what
these these phases are and this for me and for the clients was really the the mark of okay we're out of research we were into a full-blown engineering effort and really although there was a number a ton of client work going on before then most of the incredible progress has really happened since this this time point so through today there are a number of congratulations there are a number of tests nuts single client tests nuts out and a number that are in the works it's been super exciting for me personally just to be working on this project for so long and to finally see and feel
something tangible super pumped this is just some dump of a I think maybe it's Nimbus actually I'm not sure of a testament the phase one specs are happening rapidly in parallel major simplifications have been happening on that front and as I said the initial client test nuts and we just had another workshop a few days ago super productive getting everyone in the same room okay so I want to take a break from timeline and things and talk a little bit about the client architecture I know especially when I talk to community members they're very they're like okay I understand proof of work I understand
the single-chain paradigm but I really you know I was the guy that could explain everything to everyone but but I'm really struggling to understand the complexity of this this new design and so yes when you add when you take one chain and you make a thousand of them there's more complexity and when you move from proof of work to stake there's also much more complexity because proof of work although it has its problems a lot of the complexities handled extra protocol and so we're bringing that complexity in with proof of stake so there it is it is a little bit more complicated but I believe we can get an intuition for it and so as I said there's a lot of talks about this so hopefully I can get you grounded in it so we have the proof of work chain we have this is the chain we
know and love stable chugging along has the community has a lot of economic activity this in the new system is primarily serves as the economic seeds for aetherium 2.0 initially just validator deposits and so moving beyond the proof-of-work chain we have the beacon chain the beacon chain is the core system level chain for the entirety of this new system it's where the validators live it's where finality occurs so proof of stake finality where we come to consensus on which what is the head of the chain there's an R and G in there so random number generation via the participation
and commitments of different validators that's where the validator deposits live so the rewards the penalties slashing all of that occurs their rewards being if you do your job well you get rewarded if you do your job poorly you get penalized there's also a group component to that so if we all do our jobs well together we all make a little bit more money whereas if we're all doing a crappy job we might lose more money and this notion of this thing we call the shuffling validators have a number of duties at any given time and the combination of the current validator set with the output of the RNG dictates what validators need to be doing so this beacon chain is the system level chain
it's no user activity what happens here it's just this the core consensus of the system it also serves as the the backbone or maybe the spine of the chain where the shard chains are connected to shard chains are much more what we think of as a block chain at least from the user level perspective the shard chains each of these you can think of as like some very similar to the etherium 100 chain where it has accounts and transactions and user level activity these shard chains are I think I have a cool these shard chains are connected back to the beacon chain via we'll call these things cross links and so one of
the main jobs is a validator is your assigned to a shard chain where your sink you sink to the shard chain attest to the availability of the data and make you sign a commitment attempting to make a cross link back in and so we take these recent references of shard chains and put them into the beacon chain now this reference does a number of things one the the primary thing it does is that it routes the chard chain back into the beacon chain and by doing this to find the head of a chard chain I find the head of the beacon chain I find the cross link the latest cross link for the associated chard I go to that block I'm now at the chard chain and I find the head from there and so it unifies the
consensus of the chard chain back into the the beacon chain the other thing the other primary thing that these cross-links do is they serve for the basis of asynchronous communication between shards so if I have a user level transaction right here on shard one that wants to communicate to shard 1,024 a cross link is made and then a cross link at once the cross link is made a receipt that was emitted over here because the char chain over here knows about the root of the beacon chain a claim can be made about this cross about this receipt the receipt is consumed and in acts essentially a transaction on the other so these cross-links really unify and bring the chard chains back into the
beacon chain and so right so we have beacon chain we have shard chains and so as a validator what I do I have two main roles one is to create these cross-links and the other is to serve a little bit serve a little bit on a longer term role on the shard chain so maybe every week or two I get rotated from one charge or another building the shard and creating the user level block chains beyond that we have state execution so we have the data here and then we have a layer one interpretation of that data a VM almost certainly was just some stuff to work
through there okay so general architecture is generally what's going on the people are going to be going to a lot more detail on how that manifests in clients and some of the research around the different components throughout the next few days outside the core architecture we have Co ization algorithms tree hashing which is kind of a fun little way to take any object in hashed into a Merkle tree to make proofs about them BLS 1231 and BLS aggregation networking and discovery lib p2p which is a modular p2p networking stack merkel proof formats like current protocols test formats there's all sorts of stuff that sits right outside of this core architecture that really kind of puts
the clients really together cool phases development so the development of e2o is divided in broadly into three phases right now and this is to help manage the complexity phase zero is the beacon chain it's the courses from local chain simply just a validator based proof of stake chain this is what has print primarily worked on on with respect to client development so far and we do expect to launch simply this core chain without any usual activity this is for a conservative approach although it would be main net with real ethan reopen it's
real rewards and penalties it does give us some allows us to coordinate in the case of some instabilities or any issues that arise without having to deal with user level activity phase one brings in the shard chains but just shard chains as data so just coming to consensus on this data being able to build these chains link them back into the beacon chain it does not have user level activity still it doesn't have a VM and enshrined VM transactions accounts the things that you're used to and this is again to grow from the center out adding complexity this is largely a networking problem and something that I expect to
launch not too far after this phase zero phase two is to add a enshrined layer one interpretation of the data so adding accounts contracts the VM transactions data executions and the crush card transactions crushed our communications this I say the layer one interpretation because although prior to phase one we can still use this data layer for interesting things anytime we come to consensus some data any one layer two can choose to interpret that data however they want it's lots of cool scaling solutions you
can do just with the data so those are the primary phases of this this core architecture there's some stuff we've been talking about that we want to do in parallel this is not one X these are potential things that we want to do to improve one Oh utilizing - OH while - oh is being developed one thing that we wanted to do is utilize the 200 beacon chain to finalize the 100 chain this is very similar to the Casper the hybrid group of work for stake we're using a contract to finalize the proof work chain we can use the beacon chain in the same way seems like a lot of the community members are pretty into this
idea of leveraging the security of the proof working with validators and potentially reducing rewards after that we can expose the - Oh state routes so the beacon chain state route you can make proofs via the peeking chain State Route about the data and state of any of the shards so by exposing the - Oh State Route in one oh we can then leverage the shard chain data layer for tons of interesting scalable things like the one thing that's barely even talked about is using it as a date availability layer for Zeke a rollup phase and these these are not canonical letters I just throw them out there but I know a little bit
in flux but they see with the at least through phase zero and one there's no fungibility between these two systems between the the ether on these two systems and it's definitely something that the community is interested in so as we move along this if we are if we have finalized and we are exposing the state routes there is some there are some options on doing fungibility so if the community is really interested in it and it's technically feasible I might go down that path and then phase D is really just what do we do with the 100 chain there's a number of options one might be to roll and I won't go into detail right now too much time but roll the 100 chain into two Oh probably be a stateless contract
or keeping it living as this external appendage of the system that highly uses the security of the two Oh chain and just kind of lives in perpetuity there's a few there's some trade-offs here some different technical challenges and really it boils down to what the community is really wants to see progress is being made on all of these a lot of this depends on light clients - Oh light clients but again progress is made highly inflexible the path room here much work many hands that's not a minus sign that's a tilde somebody pointed out looks like a - there's approximately a hundred people working on this which is wild there are ten clients roughly of
various commitment size stability et cetera I wasn't gonna name them all but I think I'm gonna try to name them all okay Trinity Nimbus lodestar lighthouse prism Keith Paradis death has some stuff working oh man harmony somebody help me I'm sorry Artemis yes and then there's an executable high spec and an executable go stick so there's a lot of people touching this thing and beyond that they have we have all certainly we have blue p2p the protocol
labs guys are working we have white box working on this Pegasus has a research team outside of the EF like there are I'm sorry I probably I shouldn't I shouldn't have named anybody because I'm not gonna name everybody but there's tons of people working on this is super exciting okay what to expect those emojis are broken sorry about that q2 we're going to fee freeze the phase zero spec clients are going to be stable and optimizing we're gonna see more single client and multi client probably short-lived test nuts and continue this phase zero spec development upcoming client challenges in this quarter and the next really
clients are the unsung heroes of this they're taking these like crazy ideas and making them a reality and to take that and like make it a production client and like a production piece of software is like a huge undertaking so they're gonna be passing consensus s agree to optimizations up to four million validators efficient aggregation strategies both in terms of computation and bandwidth they're gonna be seeking stable networks they're going to be doing state sync strategies of working on validator ui/ux security reviews visualization tools the list goes on there's a lot of work to do they're doing the hard work if you please thank your client developers and honestly fund your client developers q3 audits and formal verification cross client CI and
fuzzing as we also increase just the tests vectors we're doing some network stress tests start to see long-standing multi-client tests nets and the phase one and phase two spec development somewhere I'm not going to claim when we're gonna freeze phase one spec development but it's gonna be getting pretty stable and at that point might have a couple of clients do some prototyping q4 towards phase zero lunch somewhere definitely around this time we will be coming up with a launch plan and enacting it there's some unknowns between here and there and instability of networks but we're gonna be getting close at this
point phase one I expect to be stable and in development and phase two the spec will be maturing TL DR it's happening it's super exciting if you want to get involved talk to me talk to the clients there's a ton to do and thank you [Applause]