Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Tim Beiko: Ethereum Foundation – The Ethereum Merge

Episode Date: July 8, 2022

The hotly anticipated Ethereum merge due later this year, will see the joining of the existing execution layer of Ethereum (the Mainnet we use today) with its new proof-of-stake consensus layer, the Beacon Chain. It eliminates the need for energy-intensive mining and instead secures the network using staked ETH. This is a truly exciting step in the Ethereum vision of more scalability, security, and sustainability.Tim Beiko, Protocol Support for the Ethereum Foundation, is heavily involved in the project. He joined us to give some deep insights into governance within Ethereum, a full update on how the merge is coming along and the next steps, and how Ethereum will look post-merge.Topics covered in this episode:Tim's background and how he got involved in the spaceUnpacking governance on EthereumThe Ethereum client ecosystemThe current state of Ethereum's testnet landscapeThe Merge: what is it, and where do we stand?What is coming next in the lead up to the merge and how is success measured?How did the very recent Sepolia test go?Scaling - what will the ecosystem look like post-merge?The Ethereum roadmapEpisode links: Nebular SummitEthereum FoundationThe MergeEthereum on TwitterTim on TwitterSponsors: ParaSwap: ParaSwap aggregates all major DEXs and makes sure you beat the market price at every single swap and with the lowest slippage - paraswap.io/epicenterChorus One: Chorus One runs validators on cutting edge Proof of Stake networks such as Cosmos, Solana, Celo, Polkadot and Oasis. - https://epicenter.rocks/chorusoneThis episode is hosted by Sebastien Couture & Joseph Schweitzer. Show notes and listening options: epicenter.tv/451

Hi, welcome to Epicenter, the show which talks about the technologies, projects, and people driving decentralization and the blockchain revolution. My name is Sibisankwichu, and I'm here today with a new co-host, Joseph Schweitzer, who I'm sure lots of you will recognize as a familiar face in the Ethereum ecosystem. Joseph, thanks for coming on and co-hosting this one with me. It's actually quite fitting since we're talking with Tim Beko, who coordinates all of Ethereum's core developer meetings, and works at the Ethereum Foundation on the protocol support team. And today we're talking about, well, all things Ethereum merge, which is quite timely because there was just a major test net merge, right like a few minutes before we started this.

So, you know, this will go out fairly soon after that happened. So this is actually quite timely. But yeah, 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 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 with most of my time at Ethereum Foundation as well.

But I'm sort of a general tinkerer. So anything in the layer one sort of blockchain space that passes the legitimacy sniff test is something that I've liked to play with for a while. And 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 insider information and really good insights.

So I'm glad to have you here. A wonderful thing about public systems is that nobody has insider information if you're paying attention. Yeah. And, yeah, Tim, thanks for joining us today. right after the merge. On Sipolia. Welcome.

On Sipolia, yeah. Yes, yeah, thanks for having me. Cool. So before we talk to Tim, I just want to tell you about our sponsors this week. Security blockchains and earning rewards needs, doesn't need to be energy intensive

or complicated. And by staking your assets with Chorus 1, you contribute to network security and earn rewards too. Corus 1 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 Corus1's white label service and their battle-proven infrastructure to participate in proof of state networks in an easy way. So head over to Corrace.1 and start your stake journey. We're also supported by Paraswap. Paraswap is a multi-chain decks 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. Paraswap is also gas-friendly and helping you keep your transactions low. They recently added support for Avalanche, Polyon, BSC, and Phantom. And you can also use periswap directly in your ledger live app if you use a ledger. In addition to that, they are also becoming a Dow. So if you have PSB tokens, that's something you can participate in, as in participate in the governance of the protocol. And the Paraswop Dow just voted the gas refund program, which will allow Paraswap Stakers to get up to 100% of gas refunds on their trades on top of their auto-compounding yield. So to learn more, visit Paraswop.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 Nebulaur summit. It's happening on the day after ECC. So during ECC Week, which is one of the largest Ethereum and Development. developer conferences in Europe, actually one of the largest blockchain developer conferences in Europe as well. Mabular 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. We'll be joined by Cosmos developers, researchers, and entrepreneurs as they discuss the challenges facing the interchane and, you know, talking about the future of the internet of blockchains. So tickets are almost sold out as we speak right now. We're going to be pulling the plug on the ticket sales soon, but you might be able to squeeze in. Check out nabular.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 get into this. Tim, tell us a little about your background and how you got involved in this work. Yeah, well, I guess, yeah, first. for having me on. Yeah, my background. So I started like getting interested in blockchains around 2013, 2014. First year, first heard about Bitcoin and got into that. Then a couple of years later, I actually heard about Ethereum through the Dow, but when the Dow was like a project and not a hack. So I heard mentions of it before, but the Dow project is really what got you to like actually try out Ethereum.

So I literally bought Ether and bought Dow tokens like the week or even maybe day before it got hacked. 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 Dow. And that was like a pretty eventful couple of weeks after that because not. not only was there this big hack, but after there was like the Ethereum Classic split, and you had to figure out like how to split your tokens in order to prevent replay attacks. And I knew like absolutely nothing about blockchain stands. So 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, I guess, way to get into the space. But after the Dow, there was like this lull where it felt like, you know, maybe Ethereum was not going to 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 getting hacked, you know, is there a set of value there? So I get following you a bit, 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 ICU boom. 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.

Clearly, you know, there's a lot of things you could do with 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, you know, like, when there were, like, ICOs and the Memple 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 or 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. So it took like about a year, but then consensus put

together a protocol team and I joined that. And so I worked I worked as part of consensus for about two and a half years on their hyperdage or base you client. So got involved in basically made that protocol work through that. And as part of that, you know, I worked a lot with folks like Hudson, who was chairing the Alcornev's calls at the time. And then around like 2020, he wanted to move on to other things. And yeah, I decided to step up and take the role there. And so since then, I've been basically coordinated.

these developer calls that we have on Ethereum, where different protocol implementation teams get together and chat about changes to Ethereum. Yeah, so that's 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? We mentioned earlier you were with the Ethereum Foundation On the protocol support side, what is protocol support? Can you just let the folks know? Yeah, yeah. So our team, it's not really well known, but 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. It was just like Hudson, you know, like floating in the org chart.

And then like since the theorem has like grown and gotten more complex in the past couple years, like basically there was just like a team put together. And, you know, there's folks like Danny and me where we obviously share these calls. There's a bunch of folks who help either like get better input and share updates to the community, like Trent. We just have folks who work on like, you know, specific stuff behind the scenes. Like there was the Sepolia merge today and someone on her team is just working on getting the hash rate on Sepolia so that we hit the merge at the right time.

And, you know, there's stuff like client grants. or organizing like workshops. So anything that basically supports like the work of researchers and core developers in the protocol is this stuff we try to help with. Yeah. I think we're getting toward the same point but may have a little bit of a delay.

Just so folks kind of get it, what does governance look like on Ethereum? 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. So I guess the very first bit that's important to know about like a theorem governance, especially relative to like other blockchains, is we don't use like coin voting or any sort of formal voting as part of the governance process.

And the rough reason there is that like we don't think that like coin holders are like the only stakeholders that we should like disproportionately optimize for. And so if we don't have coin voting, you know, it becomes a much messier process for governance to happen. And there's definitely some pros and cons to that. But I think overall it works quite well for Ethereum. And generally the way changes to the protocol would happen, you know, this is the happy path. And then we can talk about all the edge cases is, you know, someone comes up with an idea. We have a pretty open process for like proposing change.

to the protocol because all the specifications are public, you know, anyone can come and put together like a proposal to change something. We use EIPs for that. Mostly, again, there's some exceptions here, but like roughly we use EIPs. And so if you want to change something under protocol, you come, you put together an EIP, then we usually ask that you get some feedback, you know, async from people who are like, have relevant experience in the part of a theorem you're changing. So imagine 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 on like, why is the new gas price better? If you're adding something new, 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 decent shape, we have these public calls that happen every two weeks called Alcor Devs. And there's a mirror version of that for changes to the beacon chain. But for now, we can assume they're like roughly the same thing. 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.

And in practice, it's incredibly rare that like a change will be accepted like on the first, 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. 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 people? And most importantly, like,

is there a security risk to Ethereum by introducing this change? 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 go through this process, you convince everybody on the client teams that's like, okay, this change should go in. Client teams will typically then write the code for your change, write testings and whatnot. 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 a lot of projects or a lot of like other elsewhere. ones 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 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 in the process,

just because it's quite messy to have an upgrade happen where, you know, it's highly contentious. And, you know, to be clear, those have happened in the theorem in the past. But generally, if something feels like, you know, there's not, like, broad community support and there's not a strong enough rationale to, like, included despite that, then it's kind of in client teams best interest and not include it 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 Ethereum community

and who should get a say and whatnot. And I don't think there's like a single answer there. 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 will be adopted and proposing them. And in the default case, they usually end up being adopted. But it's not something we can like take for granted or force upon people. That's interesting. I mean, I think that's the first time I, I,

I heard someone really kind of explain the governance process for upgrades in Ethereum. I spent a lot more time on the cosmos side of thing. And of course, there's coin voting. And governance is an issue, I think, that affects all different blockchains, whether it's something like Bitcoin or Ethereum with its processes or, you know, blockchains with built in coin voting governance. Do you think that coin voting governance, you know, could add some level of, you useful signaling 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, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, on, you know, 10% or above 90% or above 90% or above 90%. percent buy-in. So I'm curious what your thoughts are here. Yeah, that's a good question. So I don't think it adds much at the level of a theorem L1. And that's not to say, it's not useful in other context.

But I think for us, 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. I think for any case where it's strongly in favor, we can get that signal, you know, quite easily. you know, and take, you know, let's take something like EIP 1559, right? Or like 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. And I, you know, maybe, I don't know,

maybe some of them have like invested interest in proof of work so they would poll 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, coin, you know, like coins are getting burnt and that's like, you know, undoubtedly good for coin holders. But then it's like 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. 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. Nor are they necessarily the most aligned. You know, you could argue like the client team's 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 Ethereum's thrive as like a long term, you know, infrastructure that maybe like the coin holders.

today don't have, right? Like maybe, again, if you have like a very caricatural 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. 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 being much more explicit than like all the other signals we have actually adds value. And like the root reason there is like, yeah, you're, you're 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 defy product where like the coin basically gets part of like the profits from like the operation of that defy product. I think in those cases, like, it's entirely reasonable to have the coin holders be like the main, if not sold a 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 funds, flow of fund structure and they can optimize that. 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. And, you know, again, 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 don't want to like, yeah, over-optimized for them. So, yeah, and, you know, that's as Ethereum also has had coin votes in the past.

And I'm not sure, like, we've gained much information from them. And this is not even getting to, like, the technical parts of it where, like, a lot of the ETH is not in a position where, like, it could vote. So, for example, you know, some of it is, like in a multi-sig. Some of it is, like, wrapped in defy. Some of it is, like, in cold storage. So you're not even getting like a vote of like coin holders. You're getting like a weird like vote of like the ETH that's readily available and willing to like take some sort of like procedural risk to go and vote on that.

So yeah, I'm pretty against it. But I think for some other projects like where the incentive alignment is just much closer with just coin holders, it makes it done in the sense. we will get to the merge in just a minute. I did want to just make 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.

Can you explain a little bit about what this client ecosystem looks like and 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, yeah, everything we kind of talked about, it's almost like the pre-deacon chain Ethereum, where like, yeah, we had even then, unlike other, like, black, blockchain, Ethereum has many implementation teams.

So 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, you get to the same web page, but obviously, like Chrome versus Safari, have a bunch of different features that they optimize for.

And so you can think of Ethereum client implementations as that, right? Like where there's a single specification that they follow, kind of like, you know, implementing HTTP and like DNS resolving for a browser. But then there's like a bunch of degrees of freedom that they have to improve their optimization, 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. 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 user balances live.

But now we have this beacon chain, which is the proof of stake implementation of Ethereum, and this proof of stake beacon chain also has an independent specification and a set of independent implementations for it. And that means that, like, in practice for their governance, you know, they need to cut the consensus across all these teams for changes. And now we have the merge happening, which is like the combination of the current execution chain where we remove proof of work and instead rely on the existing beacon chain 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, you know, now we have people from say the beacon chain giving input into decisions that affect the execution chain because, you know, they're affected by it and vice versa. 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 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. 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.

And the cost there is like you it's a bit harder to like for outsiders to follow the process and the specific changes. And I think, you know, as we as we merge it two together, hopefully we can preserve like the speeds that we've had from like developing these things independently and having it be a bit more modular. But also make like the process for specifying changes across the entire Ethereum stack, you know, very clear and transparent. Yeah, so that's the big thing 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. Peer reviews a bit, it feels a bit too distanced compared to what we have, right? Like, peer reviews usually like anonymous and like, it's also usually like one or a couple rounds, like very four.

and discrete sets of reviews, I think what we have is like much more fluid where like you get a bunch of reviews from your peers. 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 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 EIP 1559, which was like a popular one. Or you could take like EIP 3074, which is like another popular change that hasn't made into 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 where like yes there's a lot of public review but there's also it's also open to like anyone to come in and like in practice we get it's like we don't get every stakeholder to come in every time. But when it 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. And this is kind of what you want, right? You want like the most qualified or like the person's like the strongest opinion to be heard and to make a decision based on that. 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 running?

Yes. So that's changed a lot recently. But maybe I can share where we were at and where we're hoping to go. But Ethereum has a lot of test nets. And test is obviously useful for both application developers who can deploy their contracts to them before going to Mainnet. And for client developers, you can deploy protocol changes to them before going to Mainnet. The problem with TestNet 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 quite hard to keep them stable. And then over time, you know, as just like a normal blockchain, their history and their state size grows so it becomes harder to sync a node. So we've decided with the merge coming, like this was like a good time to revisit like what are our test nets and what do we want them to be going forward?

So basically we launched a new test set for the merge called Kiln, and this is like the first one we'll be shutting down right after the merge. And the idea there is just we wanted something earlier this year that anyone could use that was like show them what post-merge Ethereum feels like. So both infrastructure providers, smart contract developers and whatnot. So that was like a new test net that we launched. and its only purpose was like to be there as a merge test net before we merged the other ones. And so once we've merged my net, that one will go away.

And then if you look at the other like longer live test net, we basically have Gordy, Robsden, and Rinkeby, as well as Kovin. 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 a year, and now it's fully been deprecated. So if you're using Covan, basically this is not going to transition to the merge. And so you should migrate to another test net because as soon as like the merge hits, it means that the network you're using just does not reflect the state of the Ethereum network.

So yeah, Rinkabee is maintained by the Get team, and it's been around for a long time and now has like a, a large state in the history, so it makes it harder to run nodes on it. So we're also not transitioning this one through the merge. But it has 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 from now. Although as soon as the merge happened, again, it won't be a good copy of this year. Mainnet.

So it'll mostly be there for like legacy reasons. But in about a year, should be shut down. Then we had a Ropston, which was another really old test net. 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 that means like the average amount you get is really low. But then if somebody just shows up with a minor, 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 a bit annoying to maintain. and it was always quite a bit this chaotic state with like a lot of reorgs and so we actually we transitioned this one through the merge first because it felt like well, you know, it's already quite chaotic.

If we break it, it's probably the least bad test net to break. And now it's running under proof of stake but after the merge on the Ethereum main net we'll be shutting this one down as well. So sometime before the end of the year. And this leaves us two two test nets which we're going to be maintaining.

So the first is Gordy. Gordy is 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. There's like a really diverse group of validators on it. There's like a lot of enthusiasts running on Gordy. And there's also like the biggest beacon chain test net, the Prater beacon chain that's like anchored to it. So Gordy is a test net that will be maintaining going forward. We're going to run it through the merge.

It'll be the last test net we actually run through the merge. so that validators have a like dress rehearsal that they can they can try before before going on main net. But if you're if you're using Gordy, you know, it's not it's not going away anytime soon. And then lastly, because Robston and Rinkaby were like so old and like large, last fall we launched a new test net called Sepolia and this actually just transitioned to proof of stake today right before we recorded this. And this is like a new test net where the good thing about it is it's just like super lightweight to sync if you want to run a node on it. You can get up the speed in like less than an hour. 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 contracts. But we'll be, we'll be keeping this one as well and hopefully growing the amount of stuff on it over time. And the final difference between like Gordia and Cipolia is because, Gordy already had a really large validator test net. 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 Gordy. And even after the merge with Prater, you'll still be able to do that.

But because, again, like when people have these test net validators, they end up like not really caring for them. It causes some amount of instability. On Cipolia, instead, we've had like just a white. waitlisted set of validators where, where, you know, these are all like infrastructure companies and whatnot that commit to running them for multiple years. So they're, it's quite a stable experience for developers. So to recap all this,

Gordy and Sipolia are the two test sets that are like sticking around long term. This is what you should be using and you're moving to. And then the other test nets we're going to be shutting down. You should consider Kovan basically already, you know, very far down its deprecation window and the shutdown soon. Kill and the merge test net will be shut down right after the main net merge. Robson will be shut down before the end of this year and then Rinkabee will probably be shut down sometime next year, but it'll be lagging behind main net 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? Where do we stand now? Because we're talking about test nets and test net merges, what happened today. But I will just hand you the mic for a while. What's coming up? Yeah.

And again, I think it's useful to give a bit of context on like how did we get to like where we are today? And then like what are the next couple steps? 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 stable, and that if it wasn't, it wouldn't break everything else on Ethereum. So we launched it, and after it had been up and running for a while, you know, we started to the prototype, like, okay, how are we going to 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. And I just felt like really bad user experience where ideally you don't want them to have to do that.

And there was this insight in, 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. So like we mentioned, you know, Mainnet uses proof of work, but a lot of the test nets don't, right? They use 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 was this idea of like, well, what if instead of moving all the applications over from like the proof of work chain to the beacon chain, we simply had like the software that's running all the applications change what consensus algorithm is. it listens to you to get the consensus on the state of the network.

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 blockchain, and you start listening to the proof of stake beacon chain. 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 the existing chain.

So we first prototype that in May of last year. There was like a hackathon and we got some of the client teams together to prototype like could the post-merge architecture work where you have a beacon chain 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 orphans the block if not. So we prototype that in this hackathon. 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. So we spent like last summer fixing all those bugs and ironing out a design for like a final architecture. And then last fall, we prototyped the actual transition from like proof of work to proof of stake. So could you like start a network up on proof of work, start a beacon chain separately and have them transition and 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 after like a week of work, we managed to get like a first prototype of that's working where we launched a devnet and it started on proof of work,

moved over to proof of stake and it finalized on the other side. 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 basically the Christmas holidays, we had a spec for like the entire merge and post-merged Ethereum, which we felt was like pretty stable, like not perfect, but you know, roughly right. So we launched this first test step called Kinsugi. right late December. And this was just to 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 when they were using it. And we got that confirmation. We also ran a bunch of stress tests on the network, like spammed it and put nodes in weird states. And we found doing that, we found some edge cases in the spec. So we fixed all of those. And in March, we launched this killed test net, which I mentioned earlier, which was basically like, call it like 95% final spec for the merge. So we've done some small tweaks to this spec since then, but no, like, big substantive changes.

They've mostly been either like clarifications or just, you know, some edge cases that like a subset of clients were hitting and whatnot. But like the overall like functionality has stayed the same since then. And after launching Kieln, we still felt like it would be good to get 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 main net. And there's like a ton of complexity there. But then once the merge has happened, 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 node controlled by like client and testing teams, which have the hard fork. 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 merch is happening here. And then we actually run through the merge on those nodes and see what happens. And for a couple of days, also we can replay transactions from mainnet as well. So we get to see not only running through the merge on mainnet, but also are the nodes stable afterwards?

You know, can you still sink and whatnot? 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 like late March, if not multiple times a week sometimes. And that's been really good to help us test 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. 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 these shadow forks, we basically test every single possible permutation. and we want to make sure that they all work. And then when we find bugs, we obviously fix them. And this is roughly where we were like a month or two ago. And now we feel like much more confident in like the readiness of the code. We're not like 100% there yet. But we felt ready enough that it made sense to start forking the like long live test sets on Ethereum. And there were a couple of reasons for that.

The first is like with Robston, we mentioned earlier, like it's quite a chaotic test net already. So it was even if like something went wrong, it wasn't the end of the world. But we also wanted to give end users like people running validators at home the chance to run through like emerge basically. Because all these shadow forks, the nodes are basically controlled by client teams and testing teams, but it's not open to anyone to run a node. So we had this first Robston fork where we had, we had like a new beacon chain launch for Robston. and anyone could join that. And yeah, on that, you know, we had people participate and the network moved over, and generally the transition went well.

So that was good. We found some couple bugs that we then fixed. And then today we ran through the second test net at polia, and the goal there was to make sure that's like the bugs, you know, the bugs on Robson would show up again. And we're still, it generally looks like the fork went well, but we're still digging into the details and comments. through everything. Once we have that, we basically have one more test net to do before main net,

and this is goarly with the predator beacon chain. And this is a test net where, you know, we really want things to be quite ready because this is where the majority of stakers are, like, expected to, like, run through the transition with their setup in anticipation of mainnet. And it has a ton of activity as well, so it's not a test net we want to break. So once we've like debriefed on this Cipolia fork and see whether there's any issues we need to fix or address, we'll start scheduling Gordy. And then once Gordy happens, assuming it goes well, then we would look at scheduling the fork for maintenance. And the goal is really just to get as many like dry runs as we can in increasingly complex scenarios where if you start super complex from the side from the start, you're going to hit a bunch of issues. that it's going to be really hard to find a root cause.

But if you start with these small dev nets 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, much easier, sorry, to fix those bugs if you're, if you're increasing complexity as you go. But yeah, and short, it's like, yeah, we spent the past year testing. We've done one more test net today. There's one left and I assume many things go well on that one, we'd move to main net. So to recap, merge-specific dev nets, long-standing merge-specific test nets in line with these shadow forks,

upgrade the long-standing Ethereum test nets that we covered earlier, and then main net, with one more long-standing test net left to go, and that's girly? That's correct, yeah. And then Gordy with the Prater Beacon Chain, 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 from token unlocks to scalability. And some of those things are covered in the next sort of set up.

upgrades 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 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, are 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.

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 this test suite because it's possible that it's just like, you know, one client hit something during a merge, but then all of the clients actually had the bug. It just happened not to hit it. So now it's like, yeah, it's really like, fine. only through that. And then if you look out and you assume the merge has happened and we're all good,

yeah, there's obviously more things on the Ethereum roadmap beyond that. And maybe the first that you hinted at is this idea of like beacon chain withdrawals. So because the merge is like the most complicated upgrade we've done to Ethereum since probably launching Ethereum, we've tried to cut down anything that wasn't absolutely critical from it just so we can have like the smallest possible set of changes. which is already a pretty big set of changes. And the biggest cut to that is the ability for validators to withdraw their stakes back to the execution layer, so to like fully exit as a validator.

So that's like the first big feature we're planning for after the merge. Typically when we have these hard forks with new features, we'll introduce more than one. So there's a bunch of other proposals as well. But that's the stuff we'll be working on right after. 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 stakes after the merge, like the 32Eath plus, like, the rewards they've accrued. As soon as the merge happens, validators will receive transaction fees that currently go to minors, and they'll be receiving

that on the execution layer itself. So they won't be locked like, validators are on the beacon chain. So this is kind of neat. So if you are a staker or even like using a staking pool or something, you will start accruing the non-burnt part of transaction fees right after the merge. So let's talk about what happened just a couple of minutes ago, about an hour ago, the Sepolia merge.

Can you talk about that in the context of like sort of this broader roadmap and how significant it is, to the broader merge efforts? Yeah, yeah. So like we were saying, it's like the second out of three test nets. And it is like this new one, which we hope to keep stable.

And the validators on this network are like a set of, you know, client teams, testing teams, infrastructure providers. So it's not like quite anyone. Like we, because we want this network to be stable, we basically open it to like any individual or entity that can commit to running stable validators over a long period of time. But there's not just like a webpage where you can sign up and launch a validator like there is for Prater. So this was like a good test because it's like it shows us, okay, like there is still like some group of like distinct entities and individuals that need to coordinate and debug things. but it's still not as open as like the praetor beacon chain or main net.

So yeah, it's like it increases like the complexity of things. You know, because we're on this call, I haven't like been digging through all the specific things that happened. But at a high level, right before I jumped on, it seemed like, you know, the network was relatively stable. There were some parts of validators that hit like some issues or we're offline and it seems like folks are still looking into that, but we'll know better in like the next couple of days,

like, you know, what types of bugs do we hit? Were they bugs or were they actually just like configuration issues? So if they're configuration issues, this is actually quite good because it's like, you know, call it like operator error rather than like protocol problems. So that's, you know, you can just restart the validators with the right config and it works. So that's what we're looking at. I think once we have a clear picture there, we'll start thinking about, okay, when do we want to fork this last test net?

I think our bar for the last test net will be higher because we want to make sure that any staker can run through it and that it's like as close to main net as possible. And then, yeah, assuming that goes well, that we would then move to merge main net. And so this next test net, anybody would be able to run a validator on the next test net? Yeah, yeah, and you can already, right? So you don't need to wait for the merge. You can literally go and like register a validator on Prater and have it be up and ready for the merge. And if you want to also run a post-merge validator right now, you can do so on Robson.

So Robson 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, 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. After the merge, it won't be possible to do so. So if you've been using, say, infera 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, Basu, Nettermine, Geth, Aragon. And you can do all that on Robston today and register a validator and make sure that it's working.

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, like, how post-merge, what scale would look like post-merge. And, you know, I think it's interesting that, you know, Ethereum is taking this data availability approach and allowing sort of like ecosystem chains to build on top of this. on this on top of this base layer. 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 I think one interesting thing maybe also to consider is how, what are some of the interoperability? I mean, beyond like bridging and things like that.

like what is the work being done on operability to ensure that all of these different roll-ups and like chains built on top of the data availability layer will be able to 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 Ethereum, there's been this 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 it concerns itself with like arbitrary computation and state and whatnot. I think obviously the blockchain landscape has evolved a ton since then.

And like the kind of design philosophy in a way for a theorem 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, 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 and 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 emerge and use Ethereum as like more of a settlement layer. And this is what we've seen with L2s today.

And this is how we think about like scaling is the L1 chain. 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 bros. So if you imagine we improve the capacity like 10x or 100x over the next like five, 10 years, the demand for blockchain might grow like 100,000 X, right? Like we need like several order of magnitude more. And this is where things like basically layer 2s can provide that. And so and the way layer 2s work like at a very high level is that they trade off this asymmetry

where on Ethereum, it's like very expensive to run computation, but fairly cheap to store data. 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 not actually running much on a theorem L1. And ZK rollups and optimistic rollups differ in 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. And so if we could get scaling solutions such as run most computations off chain, either run like some proofs on chain or some disputes on chain, but then mostly post data, that allows like for way cheaper transaction fees and for more scale. And so today when these rollups 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 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.

And so that means that like it's still fairly expensive to store data on Ethereum. And so when you pay for like a transaction 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 Ethereum? because that'll then mean it's like cheaper for all these roll-ups to be built or conversely that they can like accommodate more demand for the same price and therefore scale. And one thing about roll-ups 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 it is not correct, have a reasonable amount of time to dispute it. And typically this is on the order of like a week, more of us.

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 either malicious or buggy transactions or like mismatch between what the L2 thinks is the state of the world and what L1 thinks the L2 state of the world is. 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 after that, you almost, like, don't really need to provide much because you can assume that, well, if there was a dispute, it would have been resolved. And if somebody wanted to make a copy of the data, then they could have done so already. 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 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, with some buffer, you know, on each side. So like I was saying, you know, roll-ups usually need this data 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 needed within a week, yeah, like maybe you need to sync a node. Literally, you know, you need to go by a computer, get an internet connection set up, get the guy come to your house, set it up,

sync your node. And, you know, this extra buffer would give you enough time that's like you could still recuperate the data that way. And so this is when we talk about like Proto-Dang sharding, 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 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 incur 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 infrastructure that we have to store like an ephemeral amount of data. But instead of having every node store a full copy of all the data, you have every node store a subset of it and do some like cryptographic checks across the peer-to-peer network to ensure that 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 don't know if it's like in the billions or trillions, but like there's an incredibly low chance of like some amount of data 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. And then those cost savings or like basically scaling bandwidth gets passed on for layer twos and other solutions to help. And so this is like roughly the vision. It's just like, can we hone in on the parts where security matter the most and like put all of our 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. But then after that, kind of outsource to, like,

the community and to the ecosystem, like, ways to store, manage that data. And, you know, your other point was around, like, like, cross, 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 not to live, but where it's probably much healthier if you see just like a market the merge and the best solutions, you know, gain traction there. Okay. So to recap slightly, 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 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, titles change, naming schemes change, and roadmaps 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 ETH II, 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 revolved around some phases. So would you say this is kind of where the roadmap stands now? It's a merge, B, these kind of optimizations, and whatever else into the future. what is today's is this sort of today's Ethereum roadmap? I guess the kind of meta part from your question is like, clearly the Ethereum roadmap has changed a lot. So it's probably naive to expect, you know, today is when it gets set in stone.

I think maybe like the biggest like conceptual change is we're a bit less like linear now than we were before. And 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 we couldn't. And so this means like when, you know, like if you looked at like, you know, this like frontier to serenity roadmap or like EAT's 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, then 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. We talked about charting. We talked, you know, we didn't talk about like MEV and proposal builder separation. And we didn't talk about, like, statelessness.

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. And I think 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 and that we don't end up in like a spot where 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 those fronts. But then, yeah, there's also a ton of work that's being done making sure the EVM stays relevant and keeps improving. And luckily, it's like they're not blocked on one on the other. And what I think happens is then, you know,

whenever something goes from the spot where it's like ready to go from research to production, then we typically will prioritize that and gets working on it. at the client level. 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 roadmap.

And that's one thing we've tried to do, like, with the naming, you know, you talked about, like, 8-2 versus each one. and today we call them like the consensus layer versus like execution layer. And I think the best naming strategy 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 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 similarly, if you look at 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 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 this is like the solution bit that's going to address them. I'll be really happy.

Obviously, it's not my call to make, but I've appreciated that we're trending in that direction. And I think we're going to have to save Proposer Builders separation for the second round. Yeah, you need someone else to come and give a two-hour talk on that. Yeah. Yeah, the next time we have someone from EF on, it'll be to answer the question, when E3? We should, you know, we need to start getting some content out, like, early about E3, you know, since our history with, you know, covering this sort of topic on EFSA. But yeah, thanks for coming on, Tim.

It's been great. And, you know, hopefully now our listeners get a much better view of, you know, the overall arch of the merge and everything that's coming up next. Certainly, I have a much better understanding now. So hopefully we can get you on again soon in a couple of months when things start to move into production. Awesome. Yeah. Thank you so much for having me.

Great. Thanks. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released.

If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.