The State of the ETH1–ETH2 Merge and the Future of the Ethereum Chain

EDCON 2020 · August 2020 · 23:31

Danny Ryan explains how Ethereum’s existing execution layer could work with Eth2’s beacon-chain consensus, separating user activity from system consensus. He reviews the proposed merge architecture and the communication between clients, then demonstrates an Ethereum execution chain running with beacon-chain validators.

Speakers

Topics

From EDCON 2020, hosted by EDCON.

Transcript

okay i am told that we are live um uh hello everyone uh i'm sorry that we could not do this in person but i'm glad that i get to talk to you today my name is danny ryan i work with the ethereum foundation on the research team primarily on layer 1 scalability and upgrades the project generally is called east 2. i do a lot of research spec writing a lot of coordination around the project in general and today here let me share my screen um today i'm talking about the future of ethereum mainnet um aka the state of the east one e3 merger aka phase 1.5 aka demerge

i did not prepare slides today i don't like preparing slides they take me a long time and i figured since i'm on my computer i can treat this more like you are my colleague and i have some notes up and some different links and i want to update you on something so it's an experiment bear with me i think it'll go okay though so um today i'm going to talk to you about a little bit of context if you solve italics caucus right before mine that is a lot of the context um a little bit of the history and into the present where we're at right now some options for the future aka what does this all mean for zero mainnet where does the theory main that fit into uh this 2 upgrade and a discussion of phase 1.5 or the merge

which is the current direction for what's going to happen to the theory mainnet i'll talk about overview structure of engineering and the progress and some huge shout outs to those engineers and researchers that are involved so moving on a little bit context some of this is very obvious ethereum is a by any standard a huge success um there's an incredible amount of innovation and usage going on but it's also bursting its themes we have pushed we are currently pushing ethereum to the limits you're seeing gas usage um through the

roof and gas prices through i actually did this put up this link last night i'm going to do a reload and see where we're at reloading reloading oh my internet might suck um anyway gas prices into the roof yep wow uh that's i think the largest i've ever seen um you see you know there are some obviously some scams ponzi schemes love ethereum but uh there's also some really interesting things going on with sexes going on with field farming going on with uh all sorts of stuff on here i don't look at this a lot um but anyway tons of innovation going on the ethereum community the ethereum dot developers the room users are really awesome and we have to

meet their needs by fulfilling the promise of having a you know global decentralized application platform um and we do have a global platform um it is decentralized and there's an application platform but it can't quite handle the scale that we're looking for so thus east 2 which is a multi-year multi-phase upgrade of ethereum's core consensus at first this is um an architecture built in parallel to the existing ethereum chain which allows for rapid iteration but sooner or later the plan is to hot swap ethereum's consensus from proof of work to the e2's and that's that's what i'm talking about today so that was some context moving on to

mystery into the present solve italics talk this has been a research even since before ethereum has launched the research and proof of stake and starting was happening a couple of years ago this was coming to a head to be implemented on mainnet this was proof of stake was a hybrid proof of stake model which was to uh slowly transition the proof of work into a full proposition system uh eip 1011 and a lot of work was done on this sharding manager contract with some old viper code which is kind of cool to see it has some of the same um constants and things that we're working with in these two today anyway these are two parallel paths that

we're attempting to not uh make two intensive changes to ethereum mainnet but to layer these new proof-of-stake and charter protocols into it these the limitations of doing this inside of a theory main net were strong it was the what we could actually handle um and do to these upgrades was limited by doing that um and we're solving all the same problems in both places and so we opted for unified uh design a more radical design which combined proof of stake and charting uh unified the two uh kind of layer one validator games into one design and i i

bring up these half uh points because people go well i wish we just did done 10 11. i wish we'd just done charting the other way it's my uh my belief that to do either of these sufficiently well we would have ended up with an architecture similar to that of what we have today with the beacon chain and these two and so playing either of these out we were going to have to continue to upgrade continue to create sophisticated consensus mechanisms until we got to essentially what we had today and unifying it was you know the better path madasha these things are on testnet today the

phase zero of east 2. you can check it out there's a lot of clients working on this thing no fewer than seven there are five on um the madosa test net right now live and actually this is really built by a small army there's tons and tons of teams and individuals banging on this thing and the dash test net i check this out every once in a while proto they quite different people producing blocks generally looks pretty healthy which is very exciting prepping for that main netwatch so some options for the future so we have this upgraded we have this e2

consensus mechanism which is proof of stake uh proof of stake and chartered consensus mechanism and we have existing ethereum mainnet often called each one um how do these things play together uh what is the relationship between the two um and what's the future of uh ethereum at each one and the context of this upgraded consistent mechanism so there's a number of things that we can do uh and these have been well researched and documented um and there's this one path that we're currently taking so let's talk about some of the things that we can do the finality gadget so the hybrid proof of work stake mechanism called eip1011 was essentially layering proof of stake on top of preferred work so the group of stakers um finalized the work chain the proof of workers still just built the chain

um this you can see this is like the beacon chain pointing back to uh the proof of work chain and finalizing chunks of it um this is doable with the current infrastructure this takes some uh breaking changes or introduces some breaking changes to the um eth1 mainnet and gets some of the benefits economic salary is nice uh but it's not like doesn't give us huge healing benefits um and as i said introduces uh some consensus complexities so this is like a nice thing to do to give us some benefit now but maybe um not worth the complexity

uh raquel dug a little bit deeper and checked it out on the way to these ones now if you don't know you see that here this is not the current path the current approach because it just doesn't quite give us that radical upgrade that we're looking for um here's kind of an extension of it once you have that finality you could potentially build a two-way bridge moving assets having a contract communicate over an asynchronous mechanism um again this is not this doesn't really fulfill the promise of these two and and and capture um the benefits of these two the full benefits for the existing ethereum chain of this existing entire community the path instead that we're following today

which is i think honestly the cleanest of these any of these other methods even if they're temporary introduce consensus complexity and kind of get us halfway there partially there and kind of like add a lot of complexity for not that much benefit so instead we're opting for uh this one is two merge which essentially is a hot swap of existing ethereums sorry like that um consensus mechanism from proof of work to the beacon chain to that shorter proof-of-stake mechanism that u2 is and sorry through as it turns out and i'll talk

about this in a minute not that big of changes and this can be done in a very transparent way meaning that current users and current dapps experience little to no friction in this migration so uh vitalik wrote up a post december 2019 that talks how we can do this in a more expressed fashion and since then we formed like a small working group in which we are writing specifications and doing some prototyping and we have some prototypes so let's dig into that so this has become

deemed the merge or phase 1.5 and talk to you a little about the overview structure of engineering and progress so if you've seen anyway talks you've seen this diagram show a great diagram thank you i've used and abused this thing um once we get to phase one we this is what the the ecosystem this is what ethereum looks like we have the current proof of work chain still chugging along we have the beacon chain which is this like core system chain for these two this is where the validators live this is where the validators do finality and this is where the validators are told which shard chain to build and validate at any given time

and the links between all of the shard chains these are the shard chains you can think of any one of these shard chains kind of like an instance of ethereum maintenance today uh executing in parallel and unified under a single consensus mechanism um and so at phase one we have short chains but we don't have state or execution on these shark chains instead they're just data availability which uh has a lot of benefits potential benefits to the ethereum ecosystem and is quite an engineering feat and so this is a very exciting state but the next stage is okay what do we do with current theorem proof of work main net well let's just roll it into one of these charts so this is the

beacon chain these are the shard change you were looking at and this is that um ethereum main at that e1 chain built just as a shard in parallel with all the other shards it is an exceptional shard exceptional meaning that it has a little bit of extra logic around its rules so these these shard blocks that are just data availability have a little bit more simple rules in that they're blocks they have signatures from proposers and they have just a blob of data there's no extra validation on that blob of data and when i say blob of data for this eth1 shard chain that blob of data is instead

can be interpreted as layer 1 transactions as user transactions that we think of today on ethereum so this exceptional eth1 chain has all the same validation rules and it's built in a similar mechanism to these other chains pressing the pressing button so here you can't do that so the field one chain has all the same consensus rules as the other shark chains they're built by the same validators but that blob of data actually has meaning with respect to layer 1. it has and it has validity rules so instead of just checking you know does this or is the proposer signature correct it doesn't

have a blob of data is the pros signature correct and can i execute that blob of data against the evm and come to a post-state route and agreement on those things like and proof of work today um so one really exciting part of this is that the what we've been building in east 2 over the past two years is essentially a piece of software that is a highly sophisticated consensus mechanism it is can handle hundreds of thousands of validators it can handle uh dozens of shards and it doesn't really care deeply what that c software is today doesn't really care deeply about

what's on those shards and thus uh whereas eth1 clients today are highly sophisticated they're they are they have a consistent mechanism proof of work works is very relatively simple compared to proof-of-stake and charting um and what the optimizations are generally on in each one client today is in the user layer then execution it's in transaction processing it's in managing the transaction mempool um and gas pricing and all sorts of stuff and so we have these two highly optimized pieces of software that are for different portions of the stack and so in the phase 1.5 vision of the software

these two pieces of software live and work together and so in the future what we expect to be an ethereum client is actually an e2 client living alongside an each one client in which in these two clients kind of the master uh the leader of the system and driving consensus and the the e1 client living which in this uh youth research post i call an e1 engine the iphone engine is providing access to state and access to execution access about user level validation um so maybe i don't i don't i wish i had a name chain name suggestion change i think each one and these two are misnomers in this uh at this point

the and it implies some sort of a sequentiality that doesn't exist instead it's it's really just separation of layers whereas each one is essentially like the user layer and these two is kind of like the system layer maybe the kernel you know maybe it's the east kernel client the user client to take from the linux nomenclature but hopefully well if one needs to those terms might be here today but uh potentially they might change um so we have the high level separation of concerns this is what that looks like these two clients the equine client the e2 client drives the e1 client via rpc and both retain this php communication

the e2 client handles the low level system stuff so it's gossiping beacon blocks attack stations and shard blocks whereas the e-flat engine is handling the transaction state sync and other user layers to dig a little bit deeper the e2 client has the beacon chain it has shard chains one of which would be the e1 shard chain has that system level state called the beacon state and it has communicates by our pc and here we have the evm we have the transaction mempool and we have that e-f1 state whether that be a stateful or stateless state if you're following the ef1x research that's

in progress migrating to stateful messages so meghal wrote this to give us a little bit more context on the scope of the merger excellent post you can check it out and guillaume from the guest team has another post about what does an ethon engine actually look like and how can we take gap and mod it to become an e-1 engine essentially it's a it's adding a consensus engine within guest should be controlled by rpc instead of by approval work or clique so there is this notion of consensus engine inside of yesterday and catalyst which is what this software is called is essentially the taking of guests and the addition of an rpc consensus

these are the minimal rpc communication calls that we need between each one these two clients block production essentially hey ease one client give me a base on your mempool give me a good block block validation uh hey i have a block can you validate it against actually executing in each one hey it blocked insertion can you insert this block into your local block tree um and setting the head if e2 drives the the fork choice and so if there's a reorg on the shard chain i tell the eth1 engine hey you need to do this reorder the nice thing is guest generally handles all these in slightly different context already today and the reorg

eventually because of economic finality needs to uh we get to have like specify a maximum depth of this and actually you know be a little bit more aggressive than pruning um mikhail wrote up actually independently wrote up what he thought the methods were going to need to be and they turned out to be exactly the same so that's a good thing um this is the code games written to mod the guest client uh to be an e5 engine it's actually it's like center lines change but a lot of it's like some stuff that got commented out and a lot of testing so it's actually not too crazy to change um and we have a uh full simulation

uh mikhail has written a phase one client written in kotlin with the help of alex from txrx who has written this like anatoly python transpiler that transpiles the pythons back into executable java code and so we have the simulation that has a number of phase one charts run and a local ethon engine runs to produce and validate blocks on a single shard and i will give you a quick demo and then i think that is all my time so let's check this out over here we have we're going to run the we're going to run an e1 chain and over

here we're going to run another eth1 chain this is going to be our producer this is going to be like our validator that's not a producer we could actually have these run in the same place but it's nice like show the separation here that you can have two different types of validators um and let's take over here in this window we're going to run an h2 client that has 512 validators and is connected to um an e1 engine for block production an ethernet engine for validating and we're going to go so things are being initialized we're setting up the bls pairs this thing's about to start running

okay here we go and things are cranking you can look at both these one engines blocks are being imported let's zoom in a little bit so we have a beacon blocks are being produced they have shard transitions from both the shard zero and shard one we have new okay so we asked the proposer econ engine can you produce a block for me um and we ask and we're doing block insertion um we're asking then the processor e1 engine so say i'm a uh on the beacon committee um i get a block i need to validate it so i validate like exposure signature and other things with respect to e2

consensus and then i validate it against um each one i execute it and plug it in and if we just follow this we're seeing a lot going on but we're seeing many spots being created we're seeing blocks being produced we're seeing blocks being validated the next step of this demo is to um oh actually i don't even know if this demo if you can see the signal oh yes i think you can the next step of this demo is to plug some of the old software that we know and love today like metamask um point it at these e1 engines and demo that we can use existing uh e1 infrastructure to

interact with the c1 charging um a lot going on uh this is one of my the more exciting pieces of the puzzle right now um i think the unification of uh ethereum mainnet with the upgraded e2 consensus um is like kind of the um most exciting thing that's happening in the next year or so it unifies different portions of stack it introduces optimized uh highly optimized consensus with highly optimized user layer and kind of like brings the vision of ease to to all of you users and

the community so i think that that's time so i'm going to call it time thank you everyone talk to you all soon you