An Overview of the Ethereum Roadmap
EDCON 2021 · 27 Aug 2021 · 13:01
Tim Beiko reviews Ethereum's roadmap from the Beacon Chain launch through Berlin and London, including changes to transaction types and fees. He explains the planned Altair upgrade and the Merge's separation of execution from consensus, then describes client interoperability testing and how existing accounts and contracts fit into proof of stake.
Speakers
Topics
From EDCON 2021, hosted by EDCON.
Transcript
hi everyone uh i'm tim baco i work for the ethereum foundation and today i'm gonna give you an overview of the ethereum roadmap um this will be kind of a quick run through in 10 to 15 minutes um and we'll have a longer panel uh scheduled right after to discuss some other interesting questions in ethereum so um first i'll just go very quickly over some recent ethereum upgrades we've had um in the past year there's been a lot that's come to the network um and the biggest thing i think you know everyone listening here is probably aware of is the launch of the beacon chain at the end of 2020 so this was a huge milestone that had been worked on for
years um and in october we finally launched the beacon chain depos contract on mainnet which needed to hit a minimum amount of ether deposited in it before it went live about a month later on november 24th we hit that amount and today we have over 22 billion dollars and 215 000 215 000 validators running on the beacon chain um so it's really been kind of a huge success in in getting this uh very technical uh upgrade up and running and you know being secure with with a very large amount of funds uh at stake in parallel to that or sorry slightly after that uh we had a big upgrade on
the ether main net called berlin there the biggest change that happened was we raised a lot of gas costs which had which were previously vulnerable to denial of service risks on the ethereum network and we also introduced eip-2718 which is a transaction envelope so kind of a wrapper that we can put around transactions which allows us to introduce many new transaction types to ethereum and this was a really useful building block for the upgrade that would come after london uh given that eip1559 would require a new type of transaction so um oh this slide is a bit wrong so it says q2q3 but uh we actually you know just had london go live on august 5th uh
like i just mentioned i'll get uh london brought eip1559 which was a huge change to how the fee market works on ethereum um we'd been working on it for over two years and it was a big improvement basically the ux of ethereum and the economics of the network so we were able to deploy this because berlin had kind of laid the groundwork for it and we also had a couple interesting changes come along with it uh one was eip2520 3529 apologies which uh changed how gas refunds work on the network so that they were not exploitable anymore by things like gas tokens um and finally we delayed the difficulty bomb during the london upgrade to
december which uh will probably have to delay once more but uh getting very close to the merge it was one of the final times we'd had to do that and we also uh had eip 3541 which uh laid the groundwork for being able to have different types of contracts in the edm right now all of the contracts follow the same rules and with eip 3541 we're able to basically uh reserve some bytes for contracts and that when we have another upgrade we can we can use those bytes to identify different uh instructions that the evm should follow for those contracts in parallel uh to this the uh
the team working on the consensus layers on the beacon chain is is working on their first network upgrade called altair this will be the first time that there's actually an upgrade to the beacon chain and while it's not bringing a ton of new functionality it it's really important because it will test the basically network upgrade function of the beacon chain and it does bring a lot of neat things like the ability to have light client support uh on the beacon chain which we don't have today and probably most importantly uh increasing the penalties uh for things like uh being slashed or being inactive so when the beacon chain launched we intentionally lowered the amount by which we would penalize people because
it was still very experimental but now that it's been live for a while um it made sense to just raise those penalties to the amount that they they should be and now as you've probably heard uh by now uh the focus is all on the merge so the merge is basically moving ethereum from proof of work to proof of stake and it's worth kind of going over um how this roadmap came to be and and why we can do the merge now so a few years ago i'm sure everyone here remembers there was this uh ethereum 2.0 roadmap with phase zero phase one and phase two so phase zero was gonna bring proof of stake then sharding was gonna
come in phase one which would be just shards that store any data on them and then in phase two we would convert these data shards to evm shards or execution environments so that we could scale computation um as we were working on this road map uh like i mentioned we got proof of stake released um but in parallel to that the community started uh working on layer two scaling solutions specifically roll-ups and we saw really really good progress on that where rollups kind of started to be a more proven way that we could scale computation where we had some initial data around them actually working and being ready to go live whereas uh all
the r d around phase two was still very early um and so the roadmap kind of shifted a bit where instead of basically having shards and then converting those shards to computation uh we thought well why don't we just have the shard store data like in phase one and then scale computation using rollups and rollups actually produce a lot of data so it would be really valuable for them to have the shards um to store that data but they'll still work without them and so they go from being kind of a must-have to scaling to a nice to have after scaling and if we did that we could also just keep a single evm chart which is the current ethereum network um running all the computations
and then uh a a month or so after that there was kind of a final refinement of this idea saying well if we're gonna have a single charge with the evm why don't we just couple that directly with the beacon chain and not make it a shard but make the beacon chain the consensus engine for the ethereum network and if you're familiar with say ethereum test nets or private networks you know that ethereum clients can already support multiple consensus algorithms right like on the gordy network uh for example they run clique uh so the they do the same thing on the on the reykjavi network and several private networks using ethereum have different consensus algorithms so it's already kind of a function of ethereum clients
to to uh be able to switch to a different consensus algorithm so the idea with the design of the merge now is instead of you know making turning the evm into something else we can simply have the current ethereum clients like geth open ethereum bay su and nethermine change their consensus algorithm to follow the proof of stake system that's being maintained by the current e2 clients rather than to follow proof of work and that's really kind of the core of the idea today to be sure that this would actually work we decided to prototype it during a long hackathon so
back in may we had a month-long hackathon where we basically ran all of these uh ethereum one clients as kind of execution layer engines for the for the post-merge system and those use the e2 clients so as a consensus layer so we used uh basically prism lighthouse taku and and nimbus as a as a consensus layer and get basu and nethermind as an execution layer running transactions so after about a month of hacking we got to a final test net which was called nocturne which was able to actually process uh blocks in a post-merge network
um and here i have a kind of a screen capture of it where uh if you're familiar with the ethereum 2.0 explorers you might have seen something that looks like this before so the first couple rows that we have here are things that are common for a beacon chain explorer so you have the graffiti that tells you you know this is lighthouse then you have the eth1 data that tells you basically that which block they're looking at on each one um and then you have something that's called the execution payload and what this does is it shows that there was a block that was sent from this lighthouse node to an execution node whether that's get basu or
whatever um and it actually processed the block and ran the transaction and reported back that this was a valid block to the consensus engine um so this is really how things will work in a post merge world where the beacon chain is the one kind of setting the head of the network coming to consensus on it and then it sends the data to the execution client which will then process the blocks add transactions to it you know make sure that everything is valid and then report that back um and again in like a couple weeks of a hackathon we were able to prove that this worked at a high level there's still a lot of open questions to this though and this is what we're working on right now
the first really big and interesting one is the concept of history and thinking versus finality so on the current ethereum chain at the proof of work one we don't have a concept of finality so every sinking mode that we use um every sinking mode that we use uh kind of has some trade-offs around the historical data but then once we move to the beacon chain um we have the concept of finality where you know past a certain point things cannot reorg so we need to figure out like how do we merge these two systems which just make very different assumptions about historical data the second big question is what the final architecture look like you know how do we want clients to communicate
with each other do we want to allow many to many connections where you're say running you know multiple beacon chains with a single execution client um and and basically what are the the design principles we want to adopt here the third big thing is testing so you know the merge is the most complicated change that we're ever gonna have done on ethereum and it's bringing two completely separate systems together so we need to make sure we have you know extensive testing architecture to support a pre-merge you know testing testing the actual transition and trusting things after so those are really the three big open questions but there's also a ton more so we've put together a merged checklist which is in
the ethereum slash pm repository on github so that's ethereum forward slash pm and this basically lists all the things we still need to figure out uh and for the things we are working on are currently figuring out there's links to you know whether it's the pr the eip or whatnot so this was a lot of information really quickly hopefully it gave you a good overview of the merge um and puja from the ethereum cathedral has put together this great design that kind of shows exactly how this all all works uh so at the top we have the ethereum 1.0 uh chain right now or what we call the execution chain you know i said we went through the berlin upgrade then london uh shanghai is uh you know a potential
upgrade we might have before the merge where if we decide to you know we need to push back the difficulty bomb and then on the e2 side um you know we have the consensus chain that's running today they're gonna have their first upgrade uh called altair um and you know late this year early next year we will have the merge and after that we'll have only a single ethereum chain uh that's running the current evm and it keeps the current states and accounts and smart contracts that we have today but that is following the beacon chain for consensus rather than proof of work so that's all i had thank you very much for your time and i hope this was helpful if you have any questions or
want to chat about this more you can find me on twitter i'm at tim baco thank you