Tim Beiko: Ethereum Foundation – The Ethereum Merge #451

Transcript

hi welcome to epicenter the the show which talks about the technologies projects and people driving decentralization and the blockchain revolution my name is sebastian and i'm here today with a new co-host joseph schweitzer who um i'm sure lots of you will recognize uh as a familiar face in the in the ethereum ecosystem uh joseph uh thanks for coming on and co-hosting this one with me it's actually quite fitting since we're talking with tim baco who coordinates all the ethereum's core developer meetings and works at the ethereum foundation on the protocol support team um and today we're talking about uh well all things ethereum merge which is quite timely because there was

just a major uh test net merge uh right like a few minutes before we started this so um you know this will go out you know fairly fairly soon after after that happens so this is actually quite timely but um yeah thanks for uh thanks for co-hosting this one joseph and maybe tell the listeners a little bit by yourself and what makes you a competent co-host on this particular topic well if i'm going to uh jump in on one i feel like this is an appropriate subject i've been around the ethereum space for a while i do communications and pr work uh with most of my time at ethereum foundation as well but i'm sort of a general tinkerer so anything in the uh layer one

sort of blockchain space that uh passes the legitimacy sniff test is something that i've liked to play with for a while and um just happy to jump in cool well yeah happy to have you on hopefully you can come on for you know most of our you know ethereum focused episodes because i think you have a lot of like insider information and uh really good insights so um glad to have you here and the wonderful thing about public systems is that nobody has insider information if you're paying attention [Music] [Laughter] yeah and uh yeah tim thanks for thanks for joining us today um right right after the uh the merge i'm cepolio welcome on sapolia yeah yes

yeah yeah thanks for having me cool so before we talk to tim i just want to tell you about our sponsors this week uh securing blockchains and earning rewards needs doesn't need to be energy intensive or complicated and by staking your assets with course one you contribute to network security and earn rewards too chorus one has been a pioneer in this space since 2018 and they secure hundreds of millions of dollars in assets on over 30 decentralized networks including solana cosmos ethereum and many others if you're an institution and you want to run your own node you can use course one's white label service and their battle proven infrastructure to participate in proof of state networks in an easy way so head over to course.one and start your stick journey we're also uh supported by paraswap

paraswap is a multi-chain dex aggregator this means that through paraswap you can easily access the liquidity of various different decentralized exchanges the protocol automatically finds the cheapest liquidity for you so you can know that you are getting the best price for your trade periscope is also gas friendly and helping you keep your transactions low they recently added support for avalanche polygon bsc and phantom and you can also use paraswap directly in your ledger live app if you use a ledger in addition to that they are also becoming endow so if you have psp tokens that's something you can participate in as in participate in the governance of the protocol and the para swapped out just voted the gas refund program uh which will allow pair swap stakers to

get up to 100 of gas uh refunds on their trades on top of their auto compounding yield so to learn more visit paraswap dot io and since we're here i also want to mention something that i think a lot of people perhaps have already noticed i'm organizing a conference in paris on july 22nd it's called nebular summit it's happening on the day after ecc so during ecc week which is one of the largest ethereum developer conferences in europe actually one of the largest blockchain developer conferences in europe as well uh nebula summit is all about celebrating the cosmos and interesting ecosystem so i hope to bring a lot of you know cosmos folks and ethereum folks together for this conference um we'll be joined by cosmos developers researchers and entrepreneurs

as they discuss the challenges facing the interchange and talking about the future of the internet of blockchains so tickets are almost sold out as we speak right now uh we're gonna be pulling the plug on the ticket sales soon but you might be able to squeeze in uh check out nebular.paris for more information and i do want to mention our sponsors who are making this possible evmos anoma club neutron agoric and celestia so with that let's uh let's get into this um tim uh tell us a little bit about your background and how you got involved um in this work yeah well i guess yeah first thanks for for having me on yeah my background uh so i i i

started like getting interested in blockchains around 2013 2014 uh first year first heard about uh bitcoin and um gotten into that uh then a couple of years later i actually heard about ethereum through the dao uh but when the dao was like a project um and uh not a hack uh so i i like heard mentions of it before but the the dao project is really what got me to like actually try out ethereum so i literally bought ether and about dow tokens like the week or even maybe day before it got hacked um and uh and then the next morning like remember reading on reddit the post

about some i think it was like say saying i think someone is draining the dao um and that was like a pretty eventful couple weeks after that because not only was there this big hack but after there was like the ethereum classic split um and you had to figure out like how to split your tokens uh in order to prevent replay attacks and and i knew like absolutely nothing about blockchain stands i was just like copy-pasting random commands in my terminal hoping that i wouldn't just lose all my coins doing so so it was like a really interesting uh i guess way to get into the space um but after the doubt there was like this this lull where it felt like you know maybe ethereum uh was not gonna be like a successful

experiment because well if this is a smart contract platform and you can't write a smart contract on it without it getting hacked um you know is there is there a ton of value there so i get i can follow in a bit uh but then in like late 2016 early 2017 you start to see a bunch of projects i use ethereum again and obviously in like by mid late 2017 there was this huge ico boom um and there i kind of realized like there would probably be a lot of demand for ethereum even if like all the applications in 2017 turned out not to work uh clearly you know there's a lot of things you could you could do with with a blockchain like that and i decided i wanted to work like at the protocol layer because as a user like it

was still pretty rough to use ethereum those days and um you know like when there were like icos and the mempool would stay congested for like hours to days it was just like a really bad experience and it felt like there's a lot you could improve there but i wasn't like an engineer researcher i was like a product manager so it took me a while to find like a product manager job working on the protocol and not on the product built on top of the protocol uh so it took like about a year but then a consensus put together a protocol team and i joined that and uh so i worked i worked as part of consensus for about two and a half years on their uh hyperledger basu uh client uh so got involved in basically made

that protocol work through that um and as part of that uh you know i worked with folks like hudson who was chairing the awkwardness calls at the time and um and then around like uh 2020 he wanted to move on to other things um and uh yeah i decided to step up and take the role there and so since then i've been basically coordinating these developer calls that we have uh on ethereum where different uh protocol implement implementation teams get together and chat about uh changes to ethereum yeah so that's how how i ended up here gotcha and before we dig into core development and

sort of how governance and acd calls all core dev calls work in general what's your role today um we mentioned earlier you were with ethereum foundation um on the the protocol support side what is protocol support can you uh just let the folks know yeah yeah so uh our team it's not pretty well known but the the team i'm on at the ef is called protocol support and it's a bit of an odd team because like before me there was no team there was just like hudson you know like floating in the orc chart um and then like since the theorem has like grown and gotten more complex uh in the past couple years like the basically it was just like a team put together and um you know there's folks

like danny and me where we uh obviously charities calls uh there's a bunch of folks who help uh either like get better input and share updates to the community like trent uh we just have folks who work on like you know specific stuff behind the scenes um like there was the sapolia merged today and someone on our team is just working on getting the hash rate on sepolia so that we hit the merge uh at the right time um and you know there's a yeah stuff like client grants or organizing like workshops um so you know anything that basically supports like the work of researchers and core developers on the protocol is stuff we we try to help with um yeah i think we're getting toward the same

point but may have a little bit of a delay um just so folks kind of get it what does governance look like on ethereum how is it how does it relate to these all-core dev calls and who decides anything okay yeah this is there's a lot to unpack here um so i guess like the very first bit uh that's that's important to know about like a theorem governance especially relative to like other blockchains is uh we don't use like coin voting or any sort of formal voting as part of the governance process um and the the rough reason there is that like we we don't think that like coin holders are like the only stakeholders that we should like disproportionately optimize for um

and and so if we don't have coin voting you know it becomes a much messier process uh for governance to happen um and there's definitely some pros and cons to that but i think overall it it works quite well for ethereum and generally the way the way uh like changes to the protocol would happen uh you know this is the happy path and then we can talk about all the edge cases is uh you know someone comes up with an idea we have we have a pretty open process for like proposing changes to the protocol because all the specifications are public um you know anyone can come and put together like a proposal to change something uh we use eips for that um mostly again there's some exceptions here but like roughly we use eips

and so if you want to change something on the protocol you come you put together an eip uh then we usually ask that you get some feedback you know async from uh people who are like have relevant experience uh in in the part of ethereum you're changing um so imagine you know you're changing gas prices or something then you'd probably reach out to some client teams you'd probably want to do some benchmarking i'm like why is the new gas price better um if you're if you're adding something new uh you know like trying to get some feedback from like the people who will use this thing that you're adding and like why is it important to them and whatnot and once you have a proposal that's like in in decent shape we have these public calls that happen every two weeks called uh awkward devs

um and there's a there's a mirror version of that for for changes to the beacon chain um but you know for now we can assume they're like roughly the same thing um so we have these public calls people come with a proposal and then discuss it and then you know client teams basically decide whether or not that this is a change they should implement um and in practice it's it's incredibly rare that like a change will be accepted like on the first uh on the first time it's presented depending on the complexity of the change you know it takes like a small number of months to like a small number of years to get that change included um and most of that time is spent just like in back and forth with protocol developers who try to

understand like does this change actually benefit uh people and and most importantly like is there security risk to ethereum by introducing this change uh so there's a long list of changes that like would be beneficial to end users but like there are outstanding security issues with them and so you know we can't like have them in ethereum then you know assume you you go through this process you convince everybody on the client teams that like okay this chain should go in um client teams will will typically then write like uh write the code for your change write testings and whatnot um and then they just end up putting out the software there still needs to be like adoption of this software by the entire

ethereum community and this is the part of ethereum governance which is like very different from from a lot of projects or a lot of like other l1 where when the client devs put out the software you can think of it as like an opinionated suggestion right like they think like okay these are the changes we should make to ethereum and um and and this is when we should make them but if people like stakers and node operators don't upgrade their nodes those changes just like don't happen and in practice you know usually by the time we've put out like a set of changes the community won't adopt them and the reason is like we try to prune changes that like we think would not be adopted earlier on

the process just because it's quite messy to have an upgrade happen where um where where you know it is highly contentious and um and you know to be clear those have happened in ethereum in the past but generally if something feels like you know there's not like broad community support and and and there's not a strong enough rationale to like include it despite that then it's kind of in client teams best interest and not included because then they're the ones who have to deal with like the fallout of a messy network upgrade so there is definitely like this check you know by like everyone involved in ethereum about the changes that go out and then we you know this often leads to like very

intractable conversations about like what is the etherium community and who should get a say and what not and i don't think there's like a single answer there um you know different change bringing out different parts of the community with strong opinions but yeah it's really this process of just like trying to come up with a set of changes that like client developers think uh what will be adopted and and proposing them and and in the default case uh they usually end up being adopted um but it's not something we can like take for granted or force upon people that's interesting i mean i i think that's the first time i i heard someone really kind of explain the you know the governance process for for upgrades in

ethereum i spent a lot more time on the on the cosmos side of things and and and of course there you know there's there's coin voting and you know governance is is an issue i think that you know affects all different blockchains whether it's you know something like bitcoin or or ethereum would say with its processes or you know blockchains with built-in uh coin-voting governance do you think that coin-voting governance you know could add some level of you useful signaling uh in ethereum governance i mean corn governance has its flaws and you know we've certainly seen that in the cosmos space recently but i think that as a signaling mechanism it's highly effective and like

we saw recently you know some proposals on um on on on some cosmos chains like get you know ninety percent or above ninety percent um uh buy-in so yeah i'm curious what your thoughts are here yeah that's that's a good question so i i don't think it adds much at the level of ethereum l1 and and that's not to say it does it's not useful in other context but i think for us um there's like two outcomes you can basically get with like your signal either it's like you know mixed or it's like strongly in favor um i think for any case we're strongly in favor we can get that signal you know quite easily um you know uh and take you know that's like something like eip1559 right or

like that even the merge right i think if you polled coin holders about the merge they would tell you they're all in favor because it reduces issuance um and i you know maybe i don't know maybe some of them have like invested interest in proof of work so they would pull against but like i my rough feeling is like you know it would probably be large majority in favor and if you take something like eip 1559 it would probably be even clearer because like okay uh coin you know like coins are getting burnt and that's like you know un uh invaluably good for coin holders um but then it's like if if we because we don't have like a formal process to gather other signals beyond like these calls and whatnot

it would sort of elevate i think like that signal above others um and it's not necessarily the thing you want to optimize for especially in the short term right like obviously you know like ether holders are like a stakeholder as part of the governance process but they're not like the only one um nor are they necessarily the most aligned um you know you could argue like the client teams developing ethereum even though they're not like the biggest coin holders by several orders of magnitudes like they have a desire to see like ethereums thrive as like a long-term you know infrastructure um that maybe like the coin holders today don't have right like maybe again if you have like a very

cultural view of this maybe like most of the coin holders today are just holding for the merge because that's a trade for them and like you know they'll move on to the next thing um and i'm not saying this is the case and i doubt it would be in practice but it's like it's not clear to me that a signal from coin holders at a specific block um being much more explicit than like all the other signals we have actually adds value um and the like the root reason there is like yeah you're like optimizing for many stakeholders and there's obviously some alignment between coin holders and the other ones but it's not like complete and i think like the more your project is like aligned with coin holders the better like those governance

votes are of a signal and if you think like imagine like a very simple hypothetical d5 product where like the coin basically gets part of like the profits from like the operation of that d5 product i think in those cases like it's it's entirely reasonable to have the coin holders be like the main if not sold the cider of governance there because it's like well they're like building this thing and this thing is like has a clear like you know business model or like flow struck funds flow of fund structure and they can optimize that and and there's not really like you know users are obviously maybe not coin holders but then the users are the ones who generate your profit so like

you want to keep them happy and this is like basically you know a pretty simple alignment problem and whereas for ethereum it's like you know like yes there's obviously like the ether or the asset but i think that's like a subset of what like people are trying to build and and what users use it for um and you know again the the very simplest example there you could say like well you know it's good for coin holders when like the fees are high and a lot of eth gets burned but that's obviously very bad for users so you so you don't want to like yeah over optimize for them um so yeah and and you know that said if here also has had coin votes in the past and i'm not sure like we've gained much information from them

um and this is not even getting to like the technical parts of it where like a lot of the eth is not in a in a position where like it could vote so for example you know some of it is like a multisig some of it is like wrapped in defy some of it is like in cold storage um so you're not even getting like a vote of like coin holders you're getting like a weird like vote of like the east that's readily available and willing to like take some sort of like procedural risk to go and vote on that um so yeah i'm i'm pretty against it um but i think for some other projects like where the incentive alignment is just much closer with just coin holders that it makes a ton of sense

um we will get to the merge in just a minute i did want to just make a uh one sort of point of clarification one further question when it comes to governance digging into the stakeholders that you were mentioning so for a lot of folks listening in it may have been a while and some of these terms consensus layer clients execution layer clients you mentioned an entire secondary call so you know in the old days all core devs was all core devs and now you kind of have these two layers happening in unison um can you explain a little bit about what this client ecosystem looks like and uh sort of your thoughts on this sort of facet of ethereum governance and where

it's headed in the years to come yeah yeah that's a great point so um yeah everything we kind of talked about it's almost like the the pre beacon chain ethereum where like yeah we had um even then unlike other like block chains the theorem has many implementation teams so like the ethereum protocol is specified using like basically math and like some some like readable but not optimized code and then there's different teams who like implement versions of this protocol and i think the best analogy is like web browsers in a way where like if you go to like ethereum.org on mozilla versus chrome versus firefox versus safari um

you you get to the same web page but obviously like chrome versus safari you have a bunch of different features that like they optimize for um and so you can think of ethereum client implementations as as that right like where there's a single specification that they follow kind of like you know implementing http and like uh dns resolving for a browser um but then there's like a bunch of degrees of freedom that they have to to improve their optimization uh stuff around sync speed database storage you know the efficiency of api requests and whatnot and so this means they all kind of get a say in the governance process right so it's not just like a single implementation team deciding this but it's basically a set of them um and to make this even more complicated in

practice now we have both like what we call the execution layer of ethereum which is the current proof of work chain where like smart contracts and and uh and user balances live um but now we have this beacon chain which is the the proof-of-stake uh implementation of ethereum and this proof-of-stake beacon chain also has an independent specification and a set of independent uh implementations for it and that means that like in practice for their governance you know they need to come to consensus across all these teams for for changes and now we have the merge happening which is like the the combination of uh the current execution chain where we remove proof of work and instead rely on on the existing beacon chain uh

to bring consensus to the network and so this means that both from like a technical but also governance perspective like these two layers will merge together where uh you know now we have people from say the beacon chain giving input into decisions that affect the execution chain because uh you know they're affected by it and vice versa um and so this is probably like what the next couple years of governance for ethereum are like is like finding like cleanly merging those two things um and i think you know there's some like interesting aspects to both of them that i think we want to preserve so i think that on the execution chain you know we have like this very open

process that's like fairly well documented and people can come into um for the beacon chain because this launched like separately from ethereum they wanted to optimize for speed and so they've they've been like much better at executing efficiently um and the cost there is like you it's a bit harder to like for outsiders to to follow the process and the specific changes um and i think you know as we as we merge it two together uh hopefully we can preserve like the the speed that we've had from like developing these things independently and and having it be a bit more modular um but also make like the process for specifying changes across the entire ethereum stack uh you know very clear and and transparent um

yeah so that's that's the big thing we'll be we'll be working on next but in short you'd say it's much more of a peer review process than it is sort of a participatory sort of token holder kind of thing it's definitely participatory um i peer review is a bit it feels a bit too distanced from like what compared to what we have right like peer review is usually like anonymous and like it's also usually like one or a couple rounds like very formal and and discrete sets of reviews i think what we have is like much more fluid where like you you get a bunch of reviews from your peers um but it's you know people are not anonymous or you

know they can be but like generally they're not or at least not all of them and and it's also it's not just open to experts this is probably the other thing as well it's like you know for example take eip1559 which was like a popular one um or you could take like eip 3074 which is like another popular change that hasn't made it to ethereum yet it's not just client devs like reviewing and deciding about this it's like the community and different parts of it like smart contract developers and whatnot will come and they'll have strong opinions and those also need to get like incorporated so it's it's this weird mix we're like yes there's a lot of public review but there's also um it's also open to like anyone to come in and and like in practice we get it's like we don't get every stakeholder

to come in every time but when a change affects like a set of stakeholders like you can be sure that someone from that group will show up and have a strong opinion um and this is kind of what you want right like you want like the most qualified or like the person like the strongest opinion to be heard and and to make a decision based based on that yeah um so can you talk a little bit about the like the test net landscape and what that looks like and what are the current test nets um running yes so that's changed a lot recently but um maybe i can i can like share where we were at and where we're hoping to go um but uh ethereum has like a lot of test

nets and um and because it's obviously useful for both application developers who can like deploy their contracts to them before going to mainnet and for client developers you can deploy protocol changes to them before going to mainnet um the problem with testnets is like they end up being very unstable over time because one like if say they run on proof of work like proof of work is not meant to run with like low hash rate and you get a bunch of volatility in terms of block times and whatnot at two if they run on proof of stake again it's like you're asking people to like run these validators for no rewards so it's it's quite hard to keep them stable and then over time you know as just like a normal blockchain uh their history and their state size grows so it becomes

harder to sync a node um so we've decided with the merge coming like this was like a good time to revisit like what are our test nets and and what do we want them to be going forward um so basically we we launched a new test set for the merge called kiln and and this is like the first one we'll be shutting down uh right after the merge and the idea there is just we wanted something uh earlier this year that anyone could use that was like show them what post merge ethereum feels like um so both infrastructure providers smart contract developers and whatnot and so that was like a new test net that we launched and its only purpose was like to um to be there as a merge test net before we merge the other ones and so

once we've merged my net that one will go away um and then if you look at like the other like longer lift test net we basically have gordy robsten and rinkeby um as well as coven coven has been like half deprecated for like over a year and now is like fully deprecated because open ethereum is basically the only software that can run validators on it and that client has been in like a semi-deprecated state for for a year and now it's it's fully been deprecated so if you're using kovan basically this is not going to transition to the merge and and and so you should migrate to another test net because as soon as like the merge hits that it means that the network you're using just does not uh

does not reflect the state of the ethereum network so yeah rinky rookie is maintained by the get team and it's been around for a long time and and now has like a large state in the history so it makes it harder to run nodes on it and so we're also not transitioning this one through the merge um but it has like a lot of applications depending on it already so we have a bit of a longer shutdown period where we'll probably have it be live for like about a year um from now although as soon as the merge happen again it won't be a good copy of the theater main net so it's most it'll mostly be there for like legacy reasons but in about a year should be shut down then we had our roxton which was another

really old test net um and this one was running on proof of work and it's always been really chaotic because getting proof of work hash rate on test nets is quite hard and and it's and that means like the average amount you get is really low but then if somebody just shows up with a minor uh you know they overwhelm the network and that causes like super quick blocks with a lot of uncles and then when they leave it causes super slow blocks so it's just it's just a bit annoying to maintain um and it was always kind of been this this chaotic state with like a lot of reorgs and and so we we actually transitioned this one through the merge first because um it felt like well you know it's already quite chaotic if we break it it's probably the least bad test at the

break and now it's running under proof of stake but um after the merge on the ethereum main net uh we'll be shutting this one down as well so uh some time before the end of the year um and this leaves us two two test nets which we're gonna be maintaining so the first is gordy gordy's also like fairly old but i think of the like call them legacy test nets it's definitely the one which has like the strongest community around it uh there's like a really diverse group of validators on it there's uh like a lot of enthusiasts running on gordy and there's also like the biggest uh beacon chain test net at the prader beacon chain that's like anchored to it um so gordy is a test that we'll be maintaining going forward uh we're going

to run it through the merge it'll be the last test net we actually run through the merge and so that validators have a like dress rehearsal that they can they can try before before going on mainnet um but if you're if you're using gordy you know it's it's not it's not going away anytime soon and then lastly uh because robsten and rinky b were like so old and and like large um last fall uh we launched a new testament called sepolia and um this actually just transitioned to proof-of-stake today right before we recorded this um and this is like a new test net where the the good thing about it is it's just like super lightweight to sync if you want to run a node on it uh you can you

can get up to speed in like less than an hour um and it just makes like really easy to maintain the downside is there's obviously not as much stuff already deployed there so there's not as much like interrupt between between contracts um but we'll be we'll be we'll be keeping this one as well and hopefully growing the amount of stuff on it over time and then the final difference between like gordy and sepolia is uh because gordy already had a really like large validator test net um we're going to keep this as like an open validator set so if you just want to try stuff on your validator on the test net you could always use gourley and even after the merge with prater like you'll still be able to do that um but because again like when people have these tests and validators they end up like not

really caring for them it causes some amount of instability um on sepolia instead we've had like just a a white listed set of validators where um where you know these are all like infrastructure companies and whatnot that that commit to running them for multiple years so they're they're it's quite a stable experience for developers so to recap all this uh gordy and septolia are the two test nets that are like sticking around long term this is what you should be using you're moving to and then the other test that's we're going to be shutting down you should consider kovan basically already you know very far down gets deprecation window and and the shutdown soon kill the merged test net will be shut down

right after the main net merge robston will be shut down before the end of this year and then uh rinkeby will probably be shut down sometime next year uh but it'll be lagging behind mainnet and so it won't be like a great staging environment anymore okay and this leads us you know if you're a developer it's good to know if you're a user you've been probably waiting to hear what is the merge uh where do we stand now um because we're talking about test nets and test net merges what happened today but uh i will just hand you the mic for a while what's coming up and

again i think this is it's useful to give a bit of context on like like how did we get to like where we are today and then like what are the next couple steps um but basically we've been testing the merge for over a year now and if you count the launch of the beacon chain it's like more like two and a half or so years and like i mentioned earlier you know we launched this beacon chain separately from the ethereum like application proof-of-work chain because at the time there's already a ton of usage on ethereum and we wanted to make sure that like the beacon chain worked and was was stable and that if it wasn't they wouldn't break everything else on ethereum so we we launched it and and after it been up and running for a while you know we started to the

prototype like okay how are we gonna actually combine these two networks together and like really early designs for this had like a migration as part of them or like users would have to move from one to the other um and i just felt like really bad user experience where ideally you don't want them to have to do that um there was this insight in uh yeah a few years ago that while the clients that run ethereum the proof of work chain today they're already used to this concept of like different consensus algorithms um so like we mentioned you know main maintenance uses uh uses proof of work but a lot of the test nets don't right they use uh what we call proof of authority

you're just different consensus engines and similarly like a lot of enterprise private networks also use like different consensus engines and so there is this idea of like well what if instead of moving all the applications over from like the proof of warching to the beacon chain we simply had like the software that's running all the applications change what consensus algorithm it listens to uh to get like to get the consensus on the state of the network um and this is like the very high level design of the merge is that once we hit a certain point the clients on the network stop listening to proof of work as a way to get the latest valid head for the for the blockchain and they start listening to the proof of stake beacon chain um and this means

that you don't need to move all the applications over from one to the other you can simply kind of use a different rule to tell you what was the latest valid block and keep kind of building on on the existing existing chain um so we first prototyped that in may of of last year and it was like a hackathon and um we got some of the client teams together to prototype like could the post-merge architecture work where you have a beacon change client that kind of keeps track of the head and then they receive blocks and they send them down to their execution client which runs the evm transactions make sure that those transactions are valid and then like confirms that or or orphans the block if

not so we prototyped that uh in this hackathon uh we got it to work so that was like good confirmation that like this design was sound you know like with the with the two clients talking to each other obviously it was a hackathon so there were a ton of bugs uh so we spent like last summer fixing all those bugs and and ironing out a design uh for for like a final architecture and then um last fall we prototyped the actual transition from like proof-of-work to proof-of-stake so um could you like start a network up on proof-of-work start a beacon chain separately and have them transition and you know not fall apart throughout and safely like finalize on the other side so we got everyone in person actually

for this for a week and uh after like a week of work we managed to get like a first prototype of that working where uh we we launched it devnet and it started on proof of work moved over to proof of stake and it finalized on the other side um and so again this was just like a week-long hackathon so there were tons of bugs and issues and we spent like all of the fall after that fixing those and by uh basically the christmas holidays we had a spec for like the entire merge and post-merge ethereum which we felt was like pretty stable like not perfect but you know roughly right so we launched this first uh test step called kenzugi um right uh like late december and this was just to like give people an

idea of like what post merge ethereum would look like for us to reach out to infrastructure providers and application developers to make sure that like you know things didn't break uh when they were using it and and and we got that confirmation uh we also ran a bunch of stress tests on the network like spammed it and and put nodes in weird states and we found doing that we found some some edge cases in the specs so we we fixed all of those and in march uh we launched this kiln test net which i mentioned earlier uh which which was i basically like call it like 95 percent final spec uh for the merge so we've done some small tweaks at this specs since then but no like big substantive changes um they've mostly been either like

clarifications or just you know some edge cases that like a subset of clients were hitting and whatnot um but like the overall like functionality has has stayed the same since then and after after launching kiln um we still felt like um it would be good to get like some more practice runs because you learn a lot like when the network runs through the merge and it's a bit weird in a way because this is code that only has to run once on mainnet um and there's like a ton of complexity there but then once the merges happen you know you never need to run through the transition again so we wanted to make sure we got like as many kind of runs of that as possible and we started doing these things called shadow forks which are basically hard forks

where we only launch a small number of nodes controlled by client and testing teams which which have the hard fork um and then we see how it goes for them so you can think of this like you know there's like thousands of nodes on like the ethereum network well we take like 10 to 100 we spin them up and we tell those like small number of nodes like hey the merge is happening here and then we we actually run through the merge on those nodes and see what happens and um and for a couple days also we can replay transactions from mainnet as well so we we get to see not only like running through the merge on mainnet but also are the nodes stable afterwards you know can you still sync and whatnot um so we've been doing these shadow forks over

and over i think we had like our 11th or 12th one earlier this week so basically like every week since since like late march if not multiple times a week sometimes um and that's been really good that to help us test like not only every client implementation but also every pairwise combination so earlier we mentioned you know there's like these clients that work on the execution chain these clients that work on the beacon chain um there's four on one side five on the other this means there's like 20 pairwise combinations of like one beacon chain and one execution client that you can get and so in the shadow forks we basically test every single possible permutation and we want to make sure that they all

work and then we find you know when we find bugs uh we obviously fix them and this is roughly like where we were like a month or two ago um and now we've you know we feel like much more confident in like the the the readiness of of of the code we're not like 100 there yet but um you know we felt ready enough that it made sense to start forking the like long-lived test nets on ethereum um and there were a couple reasons for that the first is like uh with robston we mentioned earlier like it's quite a chaotic test that's all already so it was um even if like something went wrong it wasn't the end of the world um but we also wanted to give end users like people running validators at home the chance to run

through like a merge basically because all these shadow forks uh the nodes are basically controlled by client teams and testing teams but it's not open to anyone to write a node so we had this first robson fork where we had we had like a new beacon chain launched for robston and anyone could um could join that and yeah on on that uh you know we had people participate and the network moved over and uh generally the transition went well um so that was good we found some couple bugs that that we then fixed um and then today we ran through the second test nets apolia and the goal there was to make sure that like the bugs uh you know the bugs on robson would show up again and we're still we're it generally looks like the fork went well but we're still digging

into the details and and coming through everything once we have that we basically have one more test net to do before mainnet and this is gorly with the predator beacon chain and this is a test network you know we really want things to be quite ready um because this is where the majority of stakers are like expected to like run through the transition um with their setup in anticipation of mainnet and it has a ton of activity as well so it's not a test that we want to to break um so once you know we once we've like debriefed on on this sepolia fork and and see whether there's any issues we need to fix or address uh what we'll we'll start scheduling gordy and then once gordy happens um assuming it goes well then we would look at scheduling uh

the fork for for maintenance um and the goal is really just to get as many like dry runs as we can in increasingly complex scenarios where um if you start super complex from the slide from the start you're going to hit a bunch of issues and it's going to be really hard to find a root cause but if you start with like these small devnets that you like increase complexity over and over you're always like fixing bugs at like the edge of like the complexity and it just makes it much harder to uh uh much easier sorry to fix those bugs if you're if you're increasing complexity as you go um but yeah in short it's like yeah we spent the past year testing we've done one more test net today there's one left and assuming things go where go well on that one we moved to mainnet

so to recap merge specific devnets long-standing merge specific test nets in line with the shadow forks upgrade the long-standing ethereum test nets that we covered earlier and then mainnet with one more long-standing test net left to go and that's girly that's correct yeah and then gordy with the prayer be contained and we'll just call it all gordy after it's merged so what do you look for in a successful merge and when it's done what's next so i know that a lot of work has been done on shanghai and a lot of those listening would probably be curious about so

there's some misconceptions about the merge that i'm sure you're probably very familiar with and can speak to um from token unlocks to scalability um and some of those things are are covered in uh the next sort of set of upgrades that come after so what's left coming up until the merge and then what comes next coming up until the merge is basically we want to monitor these test nets like not only right after but also like you know call it a week after so that we can still sync nodes to them and things work uh work well and you know we have a whole slew of metrics that we look at like from some pretty basic stuff like our blocks being produced to like you know

our like transaction fees for every transaction being routed to the right way so it's you know now it's really just combing through all these metrics and making sure that like things are looking good and fixing anything where it isn't um and then when we fix things you know if we find a bug we'll typically then write a test for it and then run all the clients through through this test suite because it's possible that it's just like you know one client hit something during during a emerge but then all the clients actually had the bug it just happened not to hit it um so that was like that's really like fine calmly through that um and then if you know if you look out and you assume the emergence happen and we're all good yeah there's there's obviously more things on the ethereum world map beyond that um and and maybe

the first uh that you hinted at is this idea of like beacon chain withdrawals um so because the merge is like the most complicated upgrade we've done to ethereum since probably launching the ethereum um we tried to cut down anything that wasn't absolutely critical from it just so we can have like the smallest possible set of changes uh which is already a pretty big set of changes um and and and the the the biggest like cut to that is the ability for validators to withdraw their stakes back to uh to the execution layer so to like fully exit as a validator um so that's like the first big feature we're planning uh for after the merge uh typically when we have these hard forks with with new features

we'll we'll introduce more than one so there's a bunch of other proposals as well um but that's the stuff we'll be we'll be working on right after one thing i'll note though with regards to validators and withdrawals is while validators won't be able to withdraw like their their stakes after the merge like the 32 east plus like the rewards they've accrued um as soon as the merge happens validators will receive transaction fees that currently go to miners and they'll be receiving that on the execution layer itself so they won't um they won't be locked like validators are on the beacon chain so this is kind of neat so if you are a sticker or even like using a staking pool or

something you will start accruing uh the the non-burned part of transaction fees um right after the merge yeah so let's talk about what happened uh just just a couple of minutes ago about an hour ago uh the the sepolia merged um can you can you talk about that and in the context of like sort of you know this this broader roadmap and how significant it is to um you know the broader like merge uh efforts yeah yeah so so like we were saying it's like the second out of three test nets um and it is like this new one which we hope to keep stable um and the the validators on this network are like a

set of you know client teams testing teams infrastructure providers so it's not it's not like quite anyone like we because we want uh we want this network to be stable we we basically open it to like any individual or entity that can commit to running stable validators over a long period of time um but there's not just like a web page where you can sign up and and launch a validator like there is for creator um so this was like a good test because it's like it shows us okay like there is still like some group of of of like distinct entities and individuals that need to coordinate and uh and debug things um but it's still not as open as like the the crater beacon chain or mainnet um so yeah it's

like it increases like the complexity of things um i you know because we're on this this this call i haven't like been digging through uh all the uh the specific things that that happened but at a high level uh right before i jumped on it seemed like you know that the network was was relatively stable there were some parts of validators that hit like some some issues that were offline and it seems like folks are still looking into that but we'll know better in like the next couple days like you know what types of bugs did we hit were they weren't it bugs or were they actually just like configuration issues um so if they're configuration issues this is actually quite good because it's like you know called like operator error rather than uh than like protocol problems so that's it you know you can

just restart the validators uh the wrong with the right config and it works um so that's what we're looking at i think once we have a clear picture there uh we'll start thinking about okay when do we want to fork this last test net uh i think our bar for the last test net will be higher because we want to make sure that like any staker can run through it and that it's like as close to mainnet as as uh as possible um and then yeah assuming that goes well then we would we would then move to the merge mainnet and so this next test net anybody anybody would be able to run a validator on this on this on the next test now yeah yeah and you can already right like

so you don't need to wait for the merge you can literally go and like register a validator on prater and and have it be up and ready for the merge um and if if if you want to also run a post merge validator right now you can do so on roxton so roxanne has merged and so you won't run through the actual transition but if you want to figure out okay how do i configure my validator so that like i actually get transaction fees and like uh and some validators for example today it is possible to use a third-party provider instead of running an execution layer node to track deposits um after the merge it won't be possible to do so so if you've been using say infrared or alchemy with your beacon chain clients

to track deposits you can't do that after the merge so you need to figure out okay how do i run you know base you net mine geth aragon um and you can do all that on robston today um and register a validator and make sure that it's it's working um yeah cool so as we wrap up here i think it would be interesting to maybe talk a little bit about about scaling and you know how um like how post-merge uh what what scaling would look like post-merge and uh you know i i think it's interesting that you know ethereum is is taking this data availability approach and allowing um sort of like ecosystem chains to

build on top of this on this on top of this base layer um what what is what is your view about like what this ecosystem will look like post-merge you know where will like the majority of applications live and and i think one interesting one interesting thing maybe also to consider is how what are some of the interoperability uh um i mean beyond beyond like bridging instead things like that like what is the word the the work being done on operability to ensure that all these different uh roll-ups and like chains built on top of the data availability layer we'll be able to uh talk to each other and like

do cross-chain calls and stuff like that i think you know over time in terms of just like designing your theorem there's been this this like evolution where it's like if you compare ethereum when it launched a bitcoin it was like this maximally complex blockchain relative to bitcoin right where uh you know uh it concerns itself with like arbitrary computation and state and whatnot um i think obviously the the blockchain landscape has evolved a ton since then and and like the the kind of design philosophy in a way for theorem has has kind of shifted to like okay what is the actual minimal set of things we can provide

with the highest level of security which then enable people to build uh you know applications scaling solutions and whatnot that depend on that and so you know like one very obvious shift is i decided that ethereum originally wanted to do something called execution sharding where there's a bunch of like l1 shards which each process computation in parallel that are like managed by the protocol and we've moved to this world where well instead we'd rather allow like a free market of like solutions to to emerge and use ethereum uh as like more of a settlement layer and this is what we've seen with with l2s today um and this is how you know we think about like scaling is

the l1 chain like i mean the capacity will keep improving and there's some stuff we can do but like it will not improve as quickly as like the demand for block space grows um you know so if you imagine we improve the capacity like 10x or 100x over the next like five ten years the manner for blockchain might grow like a hundred thousand x right like we need like several order of magnitude more and this is where things like basically layer twos um can provide that and so and and the way layer twos work like a very high level is that they trade off this this asymmetry where on ethereum it's like very expensive to run computation but

fairly cheap to store data um whereas on an l2 it's actually quite cheap to run computations so if you can run all your computations on l2 and post like some data about them back to l1 that allows you to like lower your fees a ton because you're just running all these computations and uh not actually running much on a theory of l1 and zk rollups and optimistic rollups differ and how like they approach this but at a high level it's like there's this asymmetry between the cost of like running operations versus posting data um and so if we could get scaling solutions that just run most computations off chain either like run like some proofs on chain or some some

disputes on chain but then mostly post data that allows like for way cheaper transaction fees and for for more scale and so um today when these these roll-ups and scaling solutions pose data back to ethereum the only mechanism they have to do so is like storing data in the blockchain forever and this has like two two consequences one is like every single node on the chain needs to process that data and two they need to hold on to it basically forever um and so that means that like it's it's still fairly expensive to store data on ethereum um and and so when you pay for like a transaction on on a layer two most of the cost you're actually paying is to store this data back on ethereum the first thing we can do there is like

okay well how do we make it cheaper to store data on on ethereum because that'll mean it's like cheaper for all these roll-ups to be built and or conversely that they can like accommodate more demand for the same price and therefore scale um and one thing about rollups is they don't actually need this data to be stored forever on the network they only needed to be posted on the network and available for like some amount of time such that people can like agree that it was there and that it was correct and if if it is not correct have like a reasonable amount of time to dispute it um and typically this is on the order of like a week more or less um so there's this like assumption within

roll ups that like if the data has been made available for roughly a week it gives time for people to like sanity check it make sure that there's no like uh either malicious or buggy transactions or or like mismatch between what the l2 thinks is the state of the world and what l1 thinks uh the l2 state of the world is um and if that happens then it's fine and so this is really the window where like you want to provide like really strong security guarantees around this data in this short period of time and and after that you almost like don't really need to provide much because you can assume that or if there was a dispute um it would have been resolved and and if somebody wanted to make a copy of the data then

they could have done so already um and so this is where we get into like this idea of data availability which is to say like what if instead of just having these l2s store data on the blockchain forever they simply post it to another place where uh it's still secured by ethereum but we don't guarantee this data is available forever we guarantee it's available roughly like for how long roll-ups need it um with some buffer you know on each side so like i was saying you know roll-ups usually need to stay left for the order of like a week and like the proposals for ethereum right now is like what if we just provided a way to make data available for like the order of like a month or something so it's like you know even if it's even if you need it within a week like

maybe you need to sync a node literally you know you need to go buy a computer get an internet connection set up get the guy come to your house set it up sync your node and and you know this extra buffer would give you enough time that like you could still recuperate the data that way and so this is when we talk about like proto dang charting this is roughly the idea is what if we added like just a data component on ethereum which is like ephemeral but still highly secure but then you can charge less for this data component because um you're not you're not basically incurring a forever storage cost you're incurring like a short duration storage cost and then the next level beyond that is what if instead of having all the nodes

on the network in cure this like short term storage costs you could scale the amount of data that you're storing have nodes only store a subset of it but then get like a really high probabilistic guarantee that the rest of the data is available on the network and this is like when we talk about like full sharding for ethereum or like bank sharding which is like the latest spec for it this is what it means is we take this this infrastructure that we have to store like a an ephemeral amount of data um but instead of having every node store a full copy of all the data you have every node source a subset of it and do some like cryptographic checks uh across the

peer-to-peer network to ensure that um other nodes are storing the rest of the data with like a really really high probability right like think you know there's like i i don't know if it's like in the billions or trillions but like there's an incredibly low chance that like some amount of data would be would be unavailable on the network and because basically by doing that you're able to scale roughly by another order of magnitude the amount of data that you have um and then those those cost savings or likes basically scaling uh bandwidth gets passed on for for layer twos and other solutions that to help um and so this is like roughly the division it's just like can we hone in on the parts where security

matter the most and like put all of her efforts there and provide like these incredibly high like security assurances that this data you know was made available that this data was like correct and that the network came to consensus on it um but then after that kind of outsourced to like the community into the ecosystem like ways to store manage that data and you know your other point was around like like cross uh you know l2 communications and stuff like that i think again that's something where it feels like the l1 protocol itself is not the place for for that to live but where it's probably much healthier if you see just like a market emerge and the best

solutions you know gain traction there okay so to recap slightly um the merge is happening and then after the merge happens we would dig into things that look like optimizations that help with scaling in l2 land but i think you know as as we come close to closing i could give you the mic back to talk a little bit about where i think some folks maybe fell off the wagon a little bit is that as research changes um titles change naming schemes change um and road maps change so for those that have maybe been on the epicenter

train for closer to a decade there are four stages to ethereum's roadmap right there's frontier homestead metropolis and serenity and that's long gone and for those that sort of came around during the ico era the question is when he eth2 which still kind of exists today in a couple of different places and people that confuse one another with supposed token name changes that don't exist but this revolves around some phases so would you say this is kind of where the road map stands now it's a merge be these kind of optimizations and whatever else into the future um what is today's is this sort of today's ethereum roadmap

i guess the kind of meta part from your your your question is like clearly the ethereum roadmap has changed a lot so it's uh it's probably naive to expect you know today is when it gets set in stone um i think maybe like the biggest like conceptual change is we're a bit less like linear now than than we were before and we because we've grown the amount of people who contribute to the protocol we're able to do stuff in parallel to a degree that like we we couldn't and um and so it seems like when you know like if you looked at like you know this like frontier the serenity road map or like eats two phase zero phase one phase two they all assume like you know it's like we're going to work

on a then we're going to work on b and we're going to work on c whereas today i think we're in a spot where like obviously we need to ship things one after the other we can't ship every single thing at the same time but there's definitely different teams and different like even within teams like people that are working on like the various you know big either issues with ethereum or like areas of improvement and they're kind of happening in parallel so like we talked about like we talked about beacon chain withdrawals uh we talked about sharding we talked you know we didn't talk about like mev and proposer builder separation and we didn't talk about like statelessness uh and we didn't talk about like the evm and continuing to improve that but those

are all like threads that are happening in parallel today um and i think at you know at a high level it's like there's some protocol related things that we need to do to ensure that a theorem like scales and is safe and like um and that we we don't end up in like a spot where there's there's like some centralized actor within the system who can like exert a really high level of control and of influence and there's a ton of work that's being done on on those fronts um but then yeah there's also a ton of work that's been done like making sure that evm stays like relevant and keeps improving um and luckily it's like they're not blocked on one

one on the other and what what i think like happens is then you know whenever something goes from the spot where it's like ready to go from research to production then we we typically will prioritize that and um and get working on it at the at the client level um and we've been lucky so far that like it's just not happened that like two r d efforts are like ready to shift at the same time and if they are in the future which it probably will happen then we'd have to decide which one is higher priority or do we want to bundle them together but yeah i think it's yeah there's not as much like a single big road map and and that's one thing we've tried to do

like with the naming you know you talked about like e2 versus each one and today we call them like the consensus layer versus like execution layer and i think the best naming strategy like going forward is just to try and like describe things like very like plainly like what they are like you know the consensus layer like helps the ethereum network come to consensus on the valid uh tip of the chain the execution layer actually runs those transactions i think once we have like sharding live you know it would be fair to call that like a data layer or like a data availability layer and and similarly if you look you know on the mev land when they start to think about like proposer builder separation it's like they're taking this one step further when they're looking at like

okay what's the role of a validator what are the different tasks that like a validator can do what are the degrees of freedom and can we just like you know segment that in even more granular detail so that we can we can analyze it better so that's my hope like i think if we if we can go from like having this like very vague like yeah terms to just saying like okay these are like the five biggest problems and we need to address them and and this is like the solution bit that's going to address them um i'll be really happy obviously it's not it's not my cultivate but uh i've i've appreciated that we're trending in that direction and i think we're gonna have to save proposer builder separation for the

second round yeah you need you need someone else to come and give a two-hour talk on that yeah yeah the next the next time we have someone from uh from ef on it'll be to answer the question when e3 [Laughter] we should uh you know we need we need to start getting some content out like early about about e3 you know um since uh you know since since our history with you know covering this sort of topic on episode um but yeah thanks uh thanks for coming on tim it's been great and uh i you know hopefully now our listeners um get a much better view of you know the overall arch of the merge and everything that's um that's coming up uh next certainly i i

have a much better understanding now so uh hopefully we can get you on again soon and uh in a couple of months uh when uh when things uh start to move into production awesome yeah thank you so much for having me great thanks