Bankless - Ethereum Merge Updates! | Tim Beiko

Episode Date: June 9, 2022

Tim Beiko of the Ethereum Foundation is here to update us on the merge.  What steps are left? What obstacles do we need to overcome? Are we merging in August like Justin Drake said? Or later? Also, there are a lot of misconceptions about the merge! We’re gonna clear them up.  ------ 📣 METAMASK | The Easiest Buy in Crypto https://bankless.cc/buy ------ 🚀 SUBSCRIBE TO NEWSLETTER:          https://newsletter.banklesshq.com/   🎙️ SUBSCRIBE TO PODCAST:                 http://podcast.banklesshq.com/   ------ BANKLESS SPONSOR TOOLS:  ⚖️ ARBITRUM | SCALED ETHEREUM https://bankless.cc/Arbitrum ❎ ACROSS | BRIDGE TO LAYER 2 https://bankless.cc/Across 🏦 ROCKET POOL | DECENTRALIZED ETH STAKING https://bankless.cc/RocketPool 👻 AAVE V3 | LEND & BORROW CRYPTO https://bankless.cc/aave ⚡️ MAKER DAO | THE DAI STABLECOIN  https://bankless.cc/MakerDAO  🦁 BRAVE | THE BROWSER NATIVE WALLET https://bankless.cc/Brave ------ Topics Covered: 0:00 Intro 7:00 The State of the Merge 12:15 Testnets 15:30 Ropsten Merge 21:13  Client Diversity 24:45 Dress Rehearsals 29:45 Knowing When to Ship 34:00 The Timeline 39:30  Approaching the Merge 47:58 Wen Merge? How Merge? 53:12 Top 5 Misconceptions 1:01:22 Closing Remarks ------ Resources: Tim Beiko on Twitter: https://twitter.com/TimBeiko?s=20&t=CI2Ox4OKbi1sqcRH98qVtg ----- Not financial or tax advice. This channel is strictly educational and is not investment advice or a solicitation to buy or sell any assets or to make any financial decisions. This video is not tax advice. Talk to your accountant. Do your own research. Disclosure. From time-to-time I may add links in this newsletter to products I use. I may receive commission if you make a purchase through one of these links. Additionally, the Bankless writers hold crypto assets. See our investment disclosures here: https://newsletter.banklesshq.com/p/bankless-disclosures

Hey guys, Bankless Nation. Welcome to another episode of State of the Nation. David, this episode, we're going to be asking Tim Beko all about the merge. Are we there yet, Tim? Are we there yet? I think we're only going to be asking Tim when merch. That's a whole show. Well, definitely we need an update on the merge because I feel like some things have happened

recently that may look, there were never dates for the merge, of course. But we want to get an assessment of actually when. But also, more importantly, what needs to happen between now and the merge Tim Bako is the person to ask about all of these things. He is a master coordinator on everything Ethereum. So, David, what else are we going to discuss with Tim today? Yeah, there are just a number of test nets that we have to get through. And so we're going to talk about each step of the test nets,

what needs to happen with each of those. There's also, like most hard forks in Ethereum, happen at that block height, but not the merge. The merge happens with a different pre-weckery, I guess, for like when actually the merge happens. So there's a bunch of information to parse apart there. And also overall, there's just like a bunch of misconceptions we want to clear up. No, the Ethereum merge will not reduce gas fees.

We're going to talk about why people think that and why it's wrong. And also just talk about like what does happen at the merge. Like does ether issuance go down. Yes, it does. But why? Will users or apps have to do anything? Can you run a node without staking? What other popular misconceptions there are?

And then, of course, what happens at? after the merge. So after we asked Tim Baker, when merge? We will be asking all about the misconceptions and the things on the horizon beyond the merge as well. But first, we're going to talk about the road to the merge. So that's what comes up next. Awesome. All right. And also, our friends over at Metamask have wanted us to tell you about the buy button inside of the Metamask wallet. I'm a super user of Metamask. It's fantastic. Use the extension. Use Metamask in mobile. But David, I haven't noticed until recently that there's actually a buy button inside of both the browser extension and inside of the mobile wallet.

What does that buy wallet unlock for people? Yeah, for me, I use it when I need to top up a wallet for gas payments, for example. It's nice because you can use the buy button in Metamask with your credit card or debit card, or it can hook also straight into your bank account. But if you just need to quickly get some, like, some eth into your wallet, the Metamask buy button is super convenient. It has a bunch of just integrations with your bank accounts via different providers. And so I believe there's wire, there's Transact, there's Moon Pay.

And so it's probably the fastest way to go from a credit card or a bank account into Ether, into your wallet. For whatever reason, maybe you need to buy a quick NFT on OpenC. Maybe you need some gas in a brand new wallet and you don't want to dock yourself. It's on both the desktop version. So listeners who are watching this on YouTube right now, you can open up Metamask and see that a little buy button. You probably didn't really think about that too often. But it's also on MetaMess Mobile as well, being probably the fastest way to get from Fiat in into crypto. You know, buy buttons. We like buy buttons more than we like sell buttons,

don't we, Ryan? Yeah, you know what? It always makes me sad whenever I pay for gas fees in ETH because I'm like, oh, I spent, I spent ETH. I don't want to spend ETH. And so it's nice to have a way to automatically buy that back right inside of the wallet extension. You know, if there was like an auto buyback option, I'd probably just click that and have MetaMask replace all of the gas fees I spent on ETH. It's the closest thing possible to paying for gas with your credit card. There you go. There you go. David, before we get into that episode with Tim, want to ask you the question I always ask, which is what is the state of the nation today?

I'm going to go ahead and guess the state of the nation is annoying, Ryan. My answer was previously we are verging, as in we are on the verge of the merge. But since like everyone is asking Tim, when merge, when merge? I'm going to go ahead and say, Ryan, that the state of the nation is really annoying for people like Tim Beiko, who's always bombarded with the question, when merge. We're about to ask him the same question. And so we're the annoying ones this week, Ryan. So, yeah, say to the name, Ryan is annoying.

Yeah, well, you know, it's kind of like the kids in the backseat of the car, right? Always asking dad and, you know, Tim's in that place. But maybe we'll save that question toward a little bit towards the end. I think it is getting close, though, David. I think we are on the verge of the merge of regardless. It's just like when exactly will that happen? And I think that's not even the most important question, right? Important question, of course, is how do we make sure we get this thing right?

because it would be very bad if, you know, we did this a little bit too early before all of the boxes were checked and before we felt secure as a community. So we'll talk about all of those things with Tim Bako. You want to say something and then we'll get to sponsors, David? Yeah, I'll say everyone's asking when merge, but no one is asking about how is the merge are doing. And so we're going to ask Tim Beko how the merge is doing right after we get through some of these fantastic sponsors that make the show possible. Rocket Pool is your friendly, decentralized Ethereum staking protocol.

You can stake your ETH with Rocket Pool and get our ETH in return, allowing you to stake your ETH and use it in DefyEye at the same time. You can get 4% on your ETH by staking it with Rocket Pool, but you can get even more by running a node. Rocket Pool is the only staking provider that allows anyone to permissionlessly join their network of validating notes. Running a rocket pool node is easier to set up than running a solo node, and you only need 16Eth to get started. Why would you do this? You get an extra 15% staking commission on the pooled ETH, so your APY is boosted. So if your boldish E's staking, you can increase your API and get some extra tokens, by adding your node to the decentralized rocket pool network,

which currently has over 1,000 independent validators. It's yield farming, but with Ethereum nodes. You can get started at rocket pool.net, and also join the rocket pool community in their Discord. You can find me hanging out there sometimes in the chat, so I'll see you there. Maker Dow is the OG Defi protocol. The Maker Dow produces dye,

the industry's most battle-tested and resilient stable coin. Using Maker, you don't need to sell your collateral if you need liquidity. Instead, you can spin up a Maker vault and use your collateral to mint dye directly. With Maker, the power. to mint new money is in your hands. The Maker protocol is extremely hardened and operated by one of the most experienced Dow's in existence. They've been here since the beginning, they've seen it all,

and so you can mint dye with the assurance that your collateral is safe. Soon, Maker will be present on all chains and L2s, so minting dye can take place on Oasis.app, Zerion, Zapper, or any other Dify protocol that you use. Follow Maker on Twitter at Maker Dow and learn from the oldest and most resilient Dow in existence. Avay is the leading decentralized liquidity protocol. And now AVEV3 is here. AVEV3 has powerful new features to enable you to get the most out of DFI, including isolation mode, which allows for many more markets to be launched with more exotic collateral types, and also efficiency mode, which allows for a higher loan-to-value ratios, and of course, portals, allowing users to port their AVE position across all of the networks

that Avey operates on, like Polygon, Phantom, Avalanche, Arbitrum, optimism, and harmony. The beautiful thing about Avey is that it's completely open source, decentralized, and governed by its community, enabling a truly bankless future for us all. To get your first crypto collateralized loan, get started at AVE.com. That's AABE.com. And also check out the AVE protocol governance forums to see what more than 100,000 Dow members are all robbing about at governance.aVe.com. Hey, guys, we are back here with Tim Bako talking all about the merge today.

It's a merge check-in. I think we're probably going to have a few of these episodes on bankless. But of course, you guys know Tim. He's been on the bankless podcast. Number of times he runs the core protocol meetings called the all core devs call, that essential ACD call that you may have heard about for Ethereum. This is where all the devs come together. They discuss what to do next with Ethereum.

They get input from all corners of the ecosystem, protocol researchers and client teams and everyone else. And Tim, of course, coordinates and is a liaison for a lot of that activity. And Tim also spends a lot of time talking to the outside world about the Ethereum roadmap. So he's the guy we can ask about the merge. Tim, how are you doing, man? It's good to have you back. Thanks. Yeah, glad to be back. So aside from yourself, I'm curious, Tim, who else can we ask the question of when merge? It's like, you know, because we would be doing this weekly if we could. Yeah, yeah. So the reason I'm happy to come on here is that this way researchers and devs are not spending their times answering these questions and they can actually work on the

merch. So yeah, they can obviously give you an answer, but hopefully they can spend their time working on it instead. I mean, Trent from the EF is another really good person for this. Like, he just likes me, like, follows all of this and has a bit more like a community role. Then he can also give you some really good answers, but he's like heads down writing all these specs. So again, you don't want him to spend too much of his time doing this stuff. We got another name. That's good. So Tim and Trent, and then this is a message to the community. Every time you ask a dev or researcher, when merge, it delays the merge by another 10 minutes, okay?

So we need to stop doing that. We need to, you know, come here. Only us. We can only do it of Tim and Trent now. But, like, so if the imagery here is, like, we are kind of the annoying kids in the back of the car asking the drivers, the developers, you know, when merge, when's this all going to happen? I guess the next follow-up question is maybe more broadly is, what mile marker are we on? Okay?

So if the road to the merge is 100 miles long, what mile marker are we on at this point in time? Are we, you know, 70, are we 80? Are we like, you know, 90, 95, something like this? Right. It's weird because it's not like a straight road, right? Like it's a winding road. And there's some turns that get added as we drive on.

Huh, Tim? Yeah, yeah. So I don't have a great, like, answer. I mean, like, at a high level, like, you know, we test nets are the last thing we do before going to Mainnet. And tomorrow we're forking the first of the three test nets we plant the fork. We did. So, and that's Robston, just to be clear. And we are forking Robston a bit earlier than we otherwise would.

because basically we're asking a bit more of node operators and stakers in this upgrade than we are in previous ones. So in previous upgrades on, say, the execution layer or even on the beacon chain, the only thing people usually have to do is download the new version of the client that they're running, and that's it. They're good to go. It takes like five minutes, and that's it. This one's a bit more complicated.

So if you're running down the beacon chain or on the execution chain or group of work chain today, you now need to download the Sutter. client, which you may not have had before, you need to configure it to work with your current client, and there's a couple extra parameters you need to set. And so because this is like a bit more complicated than previous upgrades, we figured it would be good to run Robson first as a way for people to kind of test drive this process. And we do plan to deprecate the Robson test net kind of shortly after the merge. So even if, you know, it doesn't go exactly as smoothly as we'd want, we're we're fine with that.

Because this way, you know, like home stakeholders, for example, or infrastructure providers can run through the merge on Robson, figure out if anything went wrong. We can fix all of that. And then we'll hopefully have like a much smoother deployment on like Gordy, which would be like our next test. But at a high level, you know, it's we want to run through Robson. There's two more test nets, Gordy and Cipolia. And once those are done, we move to main net. The big caveat is obviously if we found the big.

issue at any point during that, then we'll want to pause and fix that. Yeah. So in terms of steps, there's not that many steps, but it's very hard to tell you how long each of those steps can take. And each test net is actually a proof of work test net. And so every test net is going to transition into proof of stake. And so is that correct? Uh, kind of.

So two of the three are proof of work. So Robston is and Cipolia is. The Gordy test net actually runs under what's called proof of authority and that's basically we white list a bunch of nodes and we tell them you can produce a block at this at this time and we just rotate through them. So they'll all move to proof of stakes. There's only two of the three that are moving that are moving from proof of work and Robson is one of them. Yeah. Okay. And so what are we testing with every single test net, right? Each test net has various like variables and and of course the merge has a bunch of variables

with it has the consensus layer clients. It has the execution layer. clients. Let's start with Gorley, the one that's coming up here in a couple days. What are we actually testing when we merge a test net? Right. That's a good question. So Ruffston is the one that's tomorrow to be here. So yeah. So what we're testing is basically whether, you know, the code and client works as expected. But for the, and that's usually what we test on testes. It's like, you know, does this thing work as we'd expect in conditions that are more or less similar to maintenance. But for the merge, we've actually done this quite a lot of times before with these shadow forks that we've run. So these shadow forks were kind of forks that would happen on test nets or main nets, but they would only have a small number of nodes that's controlled by testing and client teams that would fork.

So we've done those, I think about 10 times so far. And so we have high confidence that like, you know, things work. And we wanted to have that extra level of confidence because the merge is such a complex change. So I think the thing that we're looking at for test nets even more today than just like the code working is whether the community like manages to like smoothly upgrade. And and basically it's like, you know, once it's happened, you know, are the validators able to run through the commands? Is it clear what type of tutorials and documentation that we need to write for them? So I think that's like the additional parts that like we're really paying a lot of attention to here. And we know that this first one probably won't be perfect just because of how kind of new and different it is.

But then hopefully for the next one, which will probably be gaudy, we can have fixed a bunch of those issues, have better documentation. So that goes smoother. And people kind of have many runs to try things on before it actually happens on main nets. And when it does happen on main net, then they have really high confidence that they're set up is correct. So this is not only a test net of the software of the protocol of the code, it's also a test net for humans, right? This is also social coordination in addition to actual code coordination. Yes. And I feel it's like it's more than 50% the social parts in this case because we've gotten quite good at two inches of technical part, you know, kind of in a more closed fashion.

So we've really improved that over the past year. But, yeah, obviously we still want to make sure that everyone in the community is able to run a node and they, yeah, they're comfortable when the merge happens on that. Okay, so we've got three test nets that we are going to run a mock merge on. It'll be a real merge for the actual test nets. And then after we merge Robson, which is the one that's actually coming up in a couple days, like, do we just need to like sit and wait and watch Robston in this post-merge state for a while? what happens after the Robson merge for the Robson network? Right. Yeah, that's a good question. So on Robson, we will definitely sit and wait and watch it.

I do suspect that'll be pretty uneventful because we've done all these shadow forks. I think the thing that we need to then wait for a bit more is the code that clients have today works, but it's still not quite as polish as we'd like it to be on maintenance. And that's really the thing where I think we'll probably move to the next test. nets once we just have like a bit more of a polished product from client teams. And this is stuff like, you know, fixing some edge case issues, having some better documentation, having some better APIs to interact with the network. So things like that.

So that when we do run the Gordy and Sepolia, it might not be 100% where we will be on mainnet in terms of code, but it'll be, you know, 90 plus percent, if not like 95 or 99. So you want it to be quite close. And again, it might happen that Robson has an issue on the network and we'll obviously watch that and monitor it and fix it if it comes up. But because we have all these shadow forks, I think we have higher confidence that the transition should actually go quite well. The other thing that we'll also see on Robson is Robson has way more integrations with products. You know, like EtherScan supports it, Metamask supports it. A bunch of applications have their, like, core test deployment on it.

And even though we've done this, also with another test set that we launched called Kiln, it'll just be useful to see, like, this is like a, I don't know, kind of top tier test net in a way that's really broadly supported. Are there any weird tooling or integration issues that aren't directly caused by, like, the code of the merge, but just like because things are changing and this tool did not plan for it. And that's definitely something we want to. And that's definitely something we want to be aware of. So say it's Robston Merge Day, which is again coming in in a couple days, what are you going to be looking at? Like what data are you trying to collect?

Or is it more of like you kind of know it when you see it kind of a moment? Yeah. So a couple of things. So one is just like does the network finalize? Is it generally stable? We have kind of a list of a bunch of metrics that we look at. So like, you know, that's like the baseline, you know, that it worked. Two, the thing that I will look at is just like, are there some big services that have issues?

You know, say ether scans stopped working. That would be bad and we want to figure out why. So that's the other big thing. And then three is it's a bit more qualitative, but it's just like, do people manage to upgrade? You know, like, for example, you're going to eat stake or discord. Is it like chaos or are people generally like okay with what happened? And I think, again, like assuming the technical stuff is correct and there's no issues there, then I suspect most of the work is about how do you just make it easy for people to use this software.

So is the merge ready isn't really like a binary yes or no. It's more of just like a vibe of like how much chaos is there post test net merge and like do we feel good about that? Right. And one thing that's worth highlighting is the reason for that is the Ethereum Network is really resilient to things being imperfect. Right. Like it's designed to assume that things are not going well. So this is why, like, we can have these shadow forks and they can go well. And even imagine a world where like proof of work is banned tomorrow or like all the miners disappear to attack the chain.

We could probably merge with the software that exists today and the network would be fine. But the question is like, then we need to spend all this time fixing all these edge cases issues on a network that's live in production with like hundreds of billions at stake. And we'd rather avoid that. It's like if we can find an issue before having it on main net rather than after, it's much better to fix it before, even though the network could probably sustain like a lot of different types of these issues. And I guess the reason for that is just like if you take a bit of a bigger view of like the entire Ethereum roadmap, you know, if we don't just want to ship the merge, you know, we have a ton of things we want to ship after. And say we ship the merge like in two weeks, but then spent the next six months fixing a bunch of bugs that are like trickier to fix because they're already on main net and stuff like that. It would just slow down everything else we have to ship after. And so it's, yeah, this is why even though it can like appear like it's ready and it's like we're not looking for like much or like things don't necessarily break super loudly.

We do want to like zoom in and find those small issues where things break are not perfect. So that, yeah, when a transition happen on main net, hopefully there's, you know, there's kind of nothing to do after and we just move on to the next thing. Yeah, the rule of thumb measure twice cut once comes to mind. The idea is that like we could merge right now if we wanted to. but we would perhaps have a lot of collateral uh collateral damage as a result of that and so what we are doing now is we are preemptively fixing that collateral damage before we move merge so that the whole entire thing is smooth rather than than rough um Tim what is like a catastrophic thing that you that you are

worried about like what keeps you up at night with like the Robston merges uh and or test net mergers that you definitely do not want to see in the actual live merge um So luckily, like, we've hit a lot of them. I think, so one thing that's, it's a bit broader than the merge, but it is this idea of client diversity. So I think we've done, we've done really good work on the consensus there side with regards to climate diversity. Prism is now well under two thirds and that's really healthy.

On the execution air side, we still have like a super strong dominance, I guess. And one thing that does keep me up at night is if we go to the merge and that stays correct, if there are cases where like the majority of the network is using Geth and there's a bug in Geph, that would be really bad. And you can imagine something like, you know, imagine that Geph has a bug which prints even just one ether or deletes one ether that it shouldn't, right? It really, it affects kind of the whole purpose of this chain, which is, you know, to have like an immutable ledger that people agree on based on a specific set of rules. So if death had an issue that broke some of those rules, and it was run by a majority of nodes, then just like on the CL side, that would be really bad for the stakers running those clients. And it would put the Ethereum community in like a very awkward spot of having to choose between like,

do we bail out, you know, potentially the majority of the chain because, you know, most people are using that, or do we actually enforce the correct protocol rules, even though it might harm the majority of the stake? the network. So that's one thing that keeps me up tonight. Like I definitely want people to try and like use other clients. And this is literally the best opportunity we'll have in Ethereum's history to reset the balance of this. And this is maybe something people don't know, but it's almost not as much a problem right now on the proof of work Ethereum because all the mining is done with Geth. So that means that if there was a bug in Gett, very weirdly like all the miners would agree on it, because they all run Geth because of FlashBots.

Whereas after the merge, FlashBots has updated their infrastructure to be client agnostic. So you don't, you know, it doesn't have to be GEP. You can run any execution layer client. But that's the big thing. It's like if people keep using Geth as a majority client on the network, and there is an issue with it, regardless of when after the merge, it doesn't have to be right out of the merge. That could put us in a really bad position.

So that does keep me up at night. So I'm kind of getting this imagery of like a, you know, a school play, right? Everyone's rehearsing for this school play, right? And people have memorized their lines. And there's all sorts of these other parties. You know, there's kind of the stage crew. You know, there's the scenery. There's the spotlight.

All of these pieces need to come together. And what you're doing now with these test nets, Tim, is you guys are doing dress rehearsals, essentially. And so, you know, there's going to be, should it just be one dress rehearsal? there should be multiple dress rehearsals. And each of these test nets provides another opportunity for a run-through of the play where everyone's lines are rehearsed and everyone knows what spot to be and that sort of thing. So the first dress rehearsal is happening within the next 48 hours or so,

the Robson test net, as you mentioned. And so I'm kind of curious. As we think about these dress rehearsals too, David asked you the question of, you know, what keeps you up at night? But what sorts of things do you anticipate could go wrong in one of these dress rehearsals? Like what's the analogy of like, you know, the lead actor forgets his lines or, you know, this actress is not in the right spot or forgets to come out from backstage? What sorts of things might happen or is it completely unpredictable?

So I think, yeah, if you look at the dress rehearsals, it's like the people don't show up. This is like the vanity. And, you know, I'll take an example, like with EtherScan, for example. Actually, Ether scans are a bit different because by default, they'll be included because they follow the chain. But let's say someone like Lido, right? Like Lido today is a pool that's just live on Mainnet in the beacon chain. And I'll pick on them because they actually have showed up since like the first test net. And I know they're actually on top of this.

But imagine a world where Lido doesn't show up. You know, they don't get any of the blog post or they see them and they don't care. And then we have the merge happen on test nets. And, you know, it looks like everything's all right. And then it comes on main net. And for some reason, Lido operators like mess up their upgrades. And either that means that they're like going offline or like at the worst, they're signing the wrong things. So they get either like a penalty because they're offline or they get slashed, which is really bad.

Even in the case of Lido, because it's like a big part of the network, if all of their operators were offline, then it might actually affect like the finalization of the chain, which would also be really bad. So I think this is like, you know, one example, just like if large projects like don't pay attention and don't do anything, it can affect obviously like their end users, but also like if they are stakers or like infrastructure providers that stakers use, it might affect like a large part of the chain and lead the like disruptions there. And and this is kind of like on proof of work, right? Like when we have these upgrades on proof of work, you want all the miners to upgrade. And you want like the software that miners use the also work and not have bugs. So I think that's like the things. Like if people just like ignore completely these, these, these blog posts and announcements that we make and they just, you know, get to main net and then do it wrong because they haven't practiced. That could be bad.

And like, I'll give you another example. It's like, for example, at the merge, transaction fees become available to validators, right? So if you're a validator, you can put in an eth address. and when you create a block, that's where the transaction fees go. But imagine something like Coinbase or Cracken, which has a staking pool, it might not be as simple for them, right? Because they have, it's not actually their ETH that they're staking, they're staking all their users' ETH.

So I suspect for them it's a bit more involved than just for like a solo validator who will just plug in their ledger address, right? Like they'll just say, okay, send the funds there. If you're Coinbase or Cracken, you might want to think about like, okay, what are we actually doing with these funds? Are we compounding them? You know, like if we get all these transaction fees, should we just give them the users now?

Should we just compound them? And so that's the type of stuff where like, you want them to have thought about these problems and have a solution for them weeks or months in advance. You don't want them to read the blog post for Mainnet and be like, oh, man, we're going to get these transaction fees now. What do we do with them? So, yeah, I think it's really just about like paying attention.

And like, and similarly, you know, one last one is like, if none of the solo staker see it, like, you know, if one solo staker missed, is the memo, Ethereum will be fine. But it's like, as a community, it's super important that we reach that part of the community and that they're aware and that, you know, it's not just big projects and infrastructure providers updating, but like if solosakers can't upgrade and none of them have upgraded, that's also, you know, super, super bad for Ethereum. So yeah, that's, that's what's, so it is. It's just like a dress rehearsal, right? There are, there are lots of different kind of actors and,

you know, participators and, you know, there's kind of a choir, maybe there's a band. And, you know, if you get one or two instruments that are off or a minor character doesn't show up in costume, like who cares? But if you have someone like Lido and they're scheduled to sing their solo at, you know, midway through the show, you know, and that doesn't go well, they don't come out on stage and you've got a real problem. So the dress rehearsal, the objective of that is to kind of just run through it all. And like, it's funny because like, how do you know that you are ready for showtime. It's like, well, when you have a few successful dress rehearsals under your belt and everyone knows where to be and then you're kind of ready to go to the show. So it is, as David

said earlier, it seems to be more like a vibe, right? Like, oh, we've done this a few times. We're feeling good about it. Everyone's now confident and we have this rough consensus that we are ready to go. But also, at some point, you do need to be like, we need to ship guys and we are ready to go because you could spend time in just dress rehearsal over and over and over again. and then the audience is never going to actually be able to see the show, and you could get stuck in that too. So I guess this is just a judgment call, is this rough consensus as far as when to ship?

And maybe that explains why it's so difficult to nail down a date. Yeah, I think so. And I think the thing that at least client teams look at is like, are they comfortable in the software that they're shipping? And we get feedback from users and, you know, both large and small on that. I think, you know, the thing that we definitely, like, if like a large or even like there's something that breaks for a bunch of small users comes up, then like, yeah, we might choose to delay things there to make sure it happens smoothly. But that's different than, you know, say in Furrah was not ready for the merge because they don't pay attention. Then that's kind of on them at some way.

It's like, you know, if they run a business, it's on them to monitor this stuff. And again, I'll pick on in Furrah because I know they actually follow this stuff. super closely and are quite involved. But like, you know, if they kind of tuned down for six months and then they're like, oh, wow, the merge is happening, we would not block it on them. Like, I mean, you know, we, and hopefully they're aware and they can prepare. And at the end of the day, you know, if infera is not ready for the merge, it is like a bad user experience for all the people using Ethereum, but it's not a threat

to the protocol, you know, and that means that say, again, imagine, you know, infera is not ready for the merge and like, I don't know, say open C's and inferr a user, while they may not like inferr as much anymore as like a, you know, a service provider and they might change something else and like that's, that's all right. So it becomes more of like a, you know, quality of product concern there. And again, I'm not saying this because I don't think infer is ready. Like I think they're very active and on top of this. So just an easy, easy example to pick on that.

Well, Tim, I'm going to have to ask you the question when merge, but I'm going to ask that question right after we get through some of these fantastic sponsors that make the show possible. Arbitrum is an Ethereum layer two scaling solution that's going to completely change how we use Defi and NFTs. Over 300 projects have already deployed to Arbitrum and the DeFi and NFT ecosystems are growing rapidly. Some of the coolest and newest NFT collections have chosen Arbitrum as their home, all the while DeFi protocols continue to see increased usage and liquidity. Using Arbitrum has never been easier, especially with the ability to deploy. directly into Arbitrum through all the exchanges, including Binance, FTX, Quibi, and Crypto.com. Once inside, you'll notice Arbitrum increases Ethereum speed by orders of magnitude for a fraction of the cost of the average gas fee.

If you're a developer who wants low gas fees and instant transactions for your users, visit Arbitrum.com. To start building your DAAP on Arbitrum. If you're a Dgen, many of your favorite dafts on Ethereum are already on Arbitrum, with many moving over every day. Go to bridge.arbitrum.io now to start bridging over your ETH and other tokens in order to experience DeFi. NFTs in the way it was always meant to be. Fast, cheap, secure, and friction-free.

The Layer 2 era is upon us. Ethereum's Layer 2 ecosystem is growing every day and we need bridges to be fast and efficient in order to live a Layer 2 life. Across is the fastest, cheapest, and most secure cross-chain bridge. With a cross, you don't have to worry about the long wait times or high fees to get your assets to the chain of your choice. Assets are bridged and available for use almost instantaneously. Across bridges are powered by Uma's optimistic Oracle to securely transfer tokens from layer two back to Ethereum. A token proposal is being deliberated as we speak in the Across Forum where community members will decide on the token distribution.

You can have your part of Across's story by joining the Discord and becoming a co-founder and helping to design the fair, fair launch of Across. If you want to bridge your assets quickly and securely, go to across.to to bridge your assets between Ethereum, Optimism, Arbitrum, or Boba networks. The Brave browser is the user-first browser for the Web3 Internet. with over 50 million monthly active users. Control your digital footprint with built-in privacy and ad blocking. Inside the Brave browser, you'll find the Brave Wallet,

the first secure crypto wallet built natively inside of a Web3 crypto browser. Web3 is freedom from big tech and Wall Street. More control and better privacy. But there's a weak point in Web3, your crypto wallet. The Brave Wallet is different. Brave Wall is built natively inside the Brave browser. No extension required, which gives the Brave Wallet an extra level of security versus other wallets. With the Brave Wallet, you can buy.

store, send and swap your crypto assets, and you can even manage your NFTs and connect to other wallets and defy apps, all from the security of the best privacy browser on the market. Whether you're new to crypto or a season pro, it's time to switch to the brave wallet. Download Brave at brave.com slash bankless and click the wallet icon to get started. All right, Bankless Nation, we are back and we've got this handy little graphic. Shout out to Trent Van Apps for putting this graphic together. And this really shows the timeline of the dependencies between now, where we are, on the very far left with that we are here indication

to where we're going on the very far right. Podcast listeners, it might be useful to open up the YouTube if you want to look at the graphic here. So just to navigate this thing, on the blue line, the blue line up top of the three lines is off-chain. These are social layer consensus choices that are being made,

and also some test net merges as well, which we've talked about. And then below we have the green consensus layer and then the red execution layer. And at the end of this graphic is when these things merge. hence the merge. And so, Tim, I'm wondering if you can walk us through this graphic.

We've already talked about the TestNet client releases Robson, Sopoldia, and Gorley. That's what is in the very near term. Robson goes live literally in the next 48 hours. But then we have some remaining steps. Can you walk us through the remaining steps between now and the merge? Right, yeah. So this assumes all the testesnets go live. We just talked about that.

So it's worth hitting on like when we get to this next step, you know, terminal difficulty, like what that is and why it matters and how the merges may be a bit different from other Ethereum upgrades. So generally, when we have an upgrade on the Ethereum proof of work chain, we use a block number. So we say, as of this number, you know, the new rules apply to the chain. And this is kind of easy for clients to handle generally, because even though there's forks on the network, what happens is like, you know, even across multiple forks, well, if you're the block before the upgrade happens, you don't have the new rules. And if you're the blog, the block after, then you do have the new rules. And it's easy to

triage between that. So even if you had imagine like three different proof of work forks kind of competing for which one is the valid one, while you just activate the fork on all three, up to when the certain height is hit. And then eventually, you know, those forks resolved. There's a single canonical chain. But it doesn't really matter that like on the two kind of side chains, you've activated the hard fork as well. It just means that the transactions in those blocks were either valid or invalid. The thing with the merge is that we want to make sure that the merge is only triggered on like one major chain, right?

Like we want it to be pretty clear that like this is where the merge is happening. So instead of using your block number, we're using the top. total difficulty of the chain. So for those who aren't familiar with proof of work, every block on a proof of work chain has a specific difficulty value, like how hard is it to mine it? And if you sum all those values together, you get the total difficulty of a chain. So it's like how hard was it to mine block one plus block two plus block three all the way to the head? And this is like a really costly measure to fake because if you want to increase the difficulty of the chain, you actually have to mine it. Whereas if you want to

wanted to increase the block number of the chain, which you could do is you could start a fork where you like really slowly drive the difficulty down to zero and then mine a bunch of blocks when the difficulty is zero. And you'd have like a really high block number on a chain that doesn't have a lot of proof of work difficulty. So by using this terminal total difficulty, what we're saying is that when we hit the specific amount of proof of work on the chain is when we would trigger the merge. And that means that if you want to create like an alternate chain there, you would have to spend a ton of money to do so. And there's not really an incentive to do that. And so we choose a specific total difficulty value, which we call the terminal total difficulty value.

And once we've exceeded that on proof of work, that's when the actual transition from proof of work to proof of stake gets triggered. And if your listeners are like super familiar with proof of work, they'll realize that this also doesn't fully guarantee you don't get reorgs because you could get like short-term reorgs like we have on mainnet basically with uncle blocks. But those are fine because basically what would happen is if you hit the TTD and there's like three blocks which satisfy kind of the condition. And the condition is like that block's total difficulty is bigger than the TTD but its parents isn't. So it's like literally the only block that's like exceeded that threshold. So if you have a couple different blocks like competing uncle blocks, you would simply have the validator pick one of those and they all be valid blocks. So, you know, they have kind of a choice over it. But they don't, there's not the risk that like somebody then reveals another completely different chain, you know, that was built months ahead, months in the past and has a higher difficulty. Like basically, if that were to happen, it's kind of the same threat model, let's say a 51% back on Ethereum. And if we assume that proof of work is secure, You know, that's not something we should hit with.

So, yeah, I'll pause here. I see you have a question, David. I think just the summary, I think that's correct, is that this TTD mechanism makes the actual event of the merge unpredictable, which makes it impossible to coordinate an attack around. Is that a good summary? It's not that it's unpredictable.

It's that it's very costly to fake. So basically, if you wanted to hit the TTD on an, alternative for it, you need to spend as much hash rate as you would do to mine the Ethereum mainnet. And so that's, and while you're doing that, you're basically foregoing. Yeah. Yeah, that you could get on maintenance. And so that's, that's kind of the thing.

It's just like, it's really costly to fake. And you don't really get anything from that attack except like messing with the merge. So, and similarly, that cost today is, is on. the order of like doing your 51% attack on Ethereum, which like you could actually get more out of, you know, if you're thinking about like ROI on your on your attack. So yeah, it's just, it's just like a higher security threshold and harder for people to tamper with. So this is the reason, Tim, you guys are using a TTD rather than a block number here, right? So I guess just to zoom out on this, on this graphic for people on YouTube or the podcast, we would talk to

about the dress rehearsals, the TestNet client releases, Robston and the others that is happening now, the TTD date will be chosen, or the TTT, the total difficulty number will be actually chosen on an all-core dev call after the successful dress rehearsals happen. And there are two- And there are two- To a live performance, basically. It's like the dress rehearsals are done, we are going to make a live performance happen, we're going to have our first big show, our only big show.

And we get to put up the posters. We get to say at TTDX, what will that be? Is that sort of a hash rate? I'm not used to thinking as dates as hash rate. Yeah, yeah. So at TTX, and you can map that back to time as precisely as a block number. So like, you know, with block numbers, we usually have like a range of days. Like we can't predict it on the day.

Exactly. But like we can do the same with. Okay. So we'll have a range of range time. And then we have two client releases. One, of course, is the consensus layer, which is the beacon chain. That's the proof of stake chain that's happening right now. And the other, of course, is the execution layer, which is the existing kind of geth,

and existing Ethereum main net. That's all proof of work. And then it sounds like there is this period that we see in the bottom of this graphic called pre-activation for both of those client releases, both Belatrix, which is the consensus, the beacon chain, and Paris, which is the existing Ethereum proof of work mainnet, that gets pre-activated and then there's some time period between the pre-activation and the actual time when the TTD number hits. Any idea on what that time range will be between pre-activation and the TTD? Are we talking like hours? We're talking days? We're talking probably

small number of weeks. Weeks? Okay. Yeah. And maybe just to take a step back and explain like why you need to run through this whole process. So like you mentioned, like, Belatrix is the name of the changes that happened on the beacon chain, which kind of allow it to speak to the current proof of work chain. And Paris is kind of the mirror image of that. It's the change we need to do on execution clients, which allow them to use the beacon chain rather than proof of work to come to consensus. And so we need those releases to be out and like those changes to be active on the network

before the transition happens. And what that means in practice is like when those changes go live, there'll be like a hard fork on the beacon chain like there was for Altair. And what happens after that hard fork is the beacon chain is just pinging the proof of work chain and saying like, have you hit TTD yet? Have you hit TTD yet? Have you hit TTV yet? And so it kind of knows to wait.

And it obviously knows what to do once the TPD is hit. And so basically because we... we want to give people time to like upgrade their nose and whatnot before the TTD is actually hit. That's why we want to have, choose a TTD value, have like this hard fork. So give people a couple weeks to upgrade their nose for the hard fork, even though the hard fork doesn't really change the functionality of either until the TTD is hit. And then give a couple more weeks for the TTD to actually be hit. And the reason there is that you don't want the TTD to be hit before the hard forked.

hard fork happens. Because that would mean that, like, the beacon chain and the execution chain aren't even aware that they should be listening for a TTD. So, like, nothing is going to happen on the TTD. And the worst case scenario is if the hard for, if the TTD was hit, kind of when only some of the nodes, but not all, have upgraded, then you'd have this weird case where, like, you know, some nodes are following the hard fork. Other nodes have no ideas happening.

And this is why having some buffers there just gives people plenty of time to know what's happening and to run the upgrades. But at the same time, also, it's worth knowing because TTD is a function of difficulty on proof of work, we don't want to predict it too far out because if the hash rate changes a ton, which we could expect to happen because the merge is happening and people might sell their GPUs, it might take us a longer time to hit it. So this is why like a small number of weeks is probably this sweep spot where like it lets people enough of a heads up to upgrade. But also, you know, imagine that like the hash rate starts dropping. Well, maybe instead of hitting it in two weeks, we hit it in three weeks. But we don't want to go from like hitting it in eight weeks to 16 weeks.

Like that would be really bad. So but that once we have the preactivation of Paris and Belatrix, both those clients, then it's just basically a countdown. It's a shot clock to TTD actually hitting. It's a drum. I'm sure we'll have charts. I'm sure we'll have websites. I'm sure we'll have you on like three or four times.

I'm sure, Tim, during the course of that, we're like just watching the clock. But when it actually cuts over, is that all like automatic? Does anything need to happen? No, it's all automatic. This is like why this is so hard. Like it would be 10 times easier to shut Ethereum down for a day and restarted on proof of stake.

Like, and seriously, like, you know, like, I don't want to put a percentage on it, but like at least 50, yeah, at least half of the work is caused by like, this has to happen like instantaneously. Like there's no doubt. Yeah, it would be much, much easier to just shut it there and down for a day and then restart it under proof of state. So we really are swapping the engine out mid-flight. Yes, yeah, yeah.

And this is why there's so much work. Because if you, from the view of a smart contract, imagine you're like a smart contract, you're on the last proof of work block. The next proof of the next block comes 12 seconds after and is proof of stake, but nothing has like changed from you. Like a small thing has around like the difficulty up codes and what not, but it's like there is no downtime. There's no for end users sending a transaction, you know, imagine you've sent the transaction

five minutes before the merge and it's pending. Like it might get included in the last proof of work block, the first proof of stake block, and there's really no difference. Like the network doesn't know. And this is why it's so important because, you know, so much of this stuff is interconnected. If we went down for even like 10 minutes, you know, imagine like how I would wreck like D5, for example.

And yeah, that's where the difficulty is. It's just like having this happen without any downtime for applications. Right. It's like it's the Indiana Jones swap where you swap on the sandbag to take off the treasure, right? It has to be instantaneous or else bad things happen. It is nice to see a core community of developers prioritize uptime to such a large degree. So I definitely do appreciate that in the D5 financial system that I envision for us in the future.

So Tim, how long would this all take after all the test nets and the Beltricks hard fork and deciding the TTD? Like, well, when I talked to Justin Drake at Permission List and Preston Van Loon, they were like, well, the ice age. is coming in August and they said that they're pretty bullish from this being able to get done in August. Do you share that August conviction or what is your perceived timeline on this whole thing? Yeah, the hard thing with timelines is like unknown unknowns, right? It's like, sure, there's a world where like everything goes right and like we merge in August. But at the same time, if you set that expectation and say we find a weird sync bug on one of these test nets and it takes us two weeks to ship a fix, then it's like, well, maybe it's not August and it's September.

And if you find two of those, then like, oh, maybe it's not early September is like mid-September. If you find like three or four, then it's like, oh, maybe it's like October. And so I think I struggle to put like a really precise month just because of that. The thing I am like really confident about is like for it to not happen in 2022, there would have to be like a really terrible thing that happens. Or like an incredibly unlikely sequence of like medium diet bad things. It's like if you told me, you know, will we find a bug for the merge? I'd say, like, sure, there's probably a good chance. What we find, like, two bad ones, like, maybe three.

That seems unlikely. But it's like, the odds of, like, finding seven or ten to me are tiny. But, like, it's not impossible, right? It could happen, but it's just very small. Or the odds of something like, I don't know, there's like a massive attack on Ethereum, right? Then we have to literally drop everything for three months and, like, fix that. Or there's like, I don't know, something like the real world, like when COVID hit in 2020. right? And like things just like go crazy for like three months. So I think like for it to not happen in

2022, something of that scale would have to happen. Either like a huge unlikely strain of like medium bad events or like something catastrophic that like hinders her ability to make progress for months. And I think then like yeah, if you're thinking about like, you know, when can it happen otherwise? It's like how many hiccups do we hit? And if we hit like none at all, then sure, August probably makes sense, but I've disappointed myself with optimistic timelines many times before. So I don't want to set the expectation that it happens in August and we find a sink bug in July and client teams feel like they can't properly fix that because they need to shift the merger month later. And so that's really the main thing, why it's hard to make a prediction.

But I do think it's like it's definitely on the order of like a couple months from now and whether it's, you know, two or four or like, I don't know, I guess the worst case would be like five now or something for the end of the year. Like that's really a function of like how many issues do we hit. But more than that, there would have to be something really bad that happens. And this late in the process, I think it's very unlikely that it would be something that has to do with the merge itself. It's almost like an like, yeah, event. Yeah, external event or, or again, like a really unlikely sequence of internal things. but it's yeah well like I said at the beginning everyone asked the question when merge but

no one really asked the question how's the merge doing and so kind of going back to the whole like it's not really a date it's more of a vibe Tim overall like how do you how do you feel you feel good I feel good like yeah I'm I'm really happy about like kind teams work like I think uh like yeah it's going well there's still some like issues were ironing out here and there but like it definitely feels like, you know, we're not only going downhill from here, but like we're quite far down the hill and that's really good. I think I'm also pretty optimistic by the fact that like I've spent the past couple months reaching out a bunch of random projects and asking them to test stuff ad hoc and like making sure that we don't have any blind spots and stuff and so far

so good there. I think the last bit of information is kind of what we talked about first on this call is like, how will home stakeholders, like, you know, run through this upgrade? Like, are they going to have a bunch of issues or not? And I hope that's not. And I've been spending the past couple of weeks trying to write these blog posts and, like, and getting client teams to write explainers about how to upgrade this. And that's something we're going to keep doing. So, like, that's the thing I'm probably most focused on right now.

But overall, yeah, I think it's been really good. I'm quite happy. All right. So maybe two to five months is kind of the time range here. It sounds like unless something catastrophic or a number of small things go wrong. Two is probably pretty optimistic. So two, we're early June. It's like I think if it was in August, it wouldn't be early August.

I think like August, you know, but I think like August to December, you can probably quote me on that. There you go. August to December. We intend to quote you on that, Tim. And then I'll also say like, you know, we won't ship the merge like past like December. It's like, yeah. Yeah, so we got the window there. So let's do this, Tim, because, you know, to kind of wrap things up, we want to create,

there's a lot of misconceptions going into the merge. We want a lightning round these misconceptions and like turn this into a YouTube video so people can clarify all of the misconceptions. And I'm going to go through five of the top misconceptions I hear about the merge and then maybe you can add. But let's just reflect on each of these and give us the reason that these things are, misconceptions and not true. So I'll go through all five. The first one is this. There is a misconception that you can withdraw your staked eth after the merge. Is that correct or incorrect?

And why? It's incorrect. So the merge is basically only the transition to proof of state. You're going to need another upgrade to have withdrawals. And the reason there is just the merge is already the most complicated change we've ever done to Ethereum. And we wanted to limit it as much as possible to make sure that it goes well. So the upgrade after the merge will have withdrawals and there's already specs being worked on for it. So if you have staked Heath guys, what this means is post merge, it'll still be locked in place. You will not be able to withdraw it, but there will be another upgrade coming down the pipeline in the order of, I don't know, months are we talking about or years and that will be another

upgrade post-merge, maybe six months time range, six months to a year, something like that? Is that what you expect him? Yeah, basically. That's usually what we do. Okay. There we go. The second misconception that we hear so often is that the merge will lower transaction fees. There's a little bit of truth here, but it's just a tiny bit of truth. Can you tell us about this? Yeah, basically. Can you tell us about this misconception? So in short, it won't basically. Like proof of work versus proof of stake doesn't change the throughput of the chain, Ethereum strategy to lower transaction fees is roll-ups and making it as cheap as possible to use them. And so that'll be a whole utter series of upgrades, which is also starting

to be worked on. Okay. So the merge will not lower transaction fees, folks. Number three, misconception, the merge will lower ETH issuance. Actually, that one's not a misconception. That's true. Yeah. That's actually true. So proof of work, issuance. I don't have the numbers in front of me, But it's like, on the order of like down to 4.6%. A 0.46%. Yeah. So in the way I look at it is if you go on an ether scan, they have like an issuance chart for mainnet. And it's like four lines in it.

There's like proof of work issuance, proof of work uncle issuance, proof uncle rewards issuance and then they eat two issuance a beacon chain. And so if you look at that, like you can literally remove the three first lines and you just have the proof of stake issuance left. And it's about 90%. Like the proof of stake issuance is about 10% of the total. So it's about a 90% reduction. It varies like on a daily basis.

You know, there's some error bars on these numbers. But like, yeah, there is a massive issuance reduction. So putting that in misconception format, some people think that the merge will increase if eth issuance. And it won't. It will decrease eth issuance. Total eth supply, at least issuance over time will be decreased. over time. Number four, there's a misconception that users' applications will have to do some work

to upgrade, maybe click a button and download something. What is that misconception? What will users and applications need to actually do post-merge? So, again, if you run a node or you're a staker, or you're an infrastructure provider, like, you definitely need to do stuff. Blog.etheum.org has the whole list. If you're just using Ethereum, like sending transactions, or deploying smart contracts, basically you need to do nothing. Everything will keep working as is. The one small thing I'll say for smart contracts is if you use the block time, or if you use the block number as a like proxy for time, that changes a bit.

So like today blocks are about 13 seconds with a lot of variance. After the merge, they're always like a multiple of 12 seconds. So like for some yield farms and like API products, like that matters. because if you calculate like a certain API over a certain number of blocks, after the merge, you're going to be issuing it slightly quicker. But it's not like a, you don't have to do anything. That will just happen. You should be aware of that.

And if you want to upgrade your contracts, you should. But that's really like the only thing that can affect how applications work. So if you are a regular everyday normal user not running a eth node, there's nothing you will have to do. If you're just using metamask, continue just using Metamask. We want to click any buttons. There's no upgrade. It will roll over automatically. Yes.

The fifth misconception is you can't run a node, an Ethereum node, without staking. So without 32Eth, for example. Can you tell us about why is that a misconception, Tim? Yes. So there's two types of nodes, right? On the network, there's validators, which are nodes that produce blocks, which are like miners today. To run one of those, you do need to run, you do need to put 32Eth.

And every 32-eath gets you like an extra validator slot. And you can think of it as a lottery. Like every block, there's an lottery. And your 32-eat is like your tickets to like potentially produce the next block. So if you want to do that and be a validator on the network, you need that capital. If you want to run a note on the network, that's different from being a validator. And what running a note means is you actually verify that the blocks and transactions that these validators create are valid. So validator is like a really bad term because the validator.

doesn't just verify. What they do, all the nodes verify on the network. What the validator does, in addition to that, is they produce the block. And this is why, like, in MEV, they call them block producers, not validators. But if you're just a normal user and you want to make sure that the blocks that are being propagated on the network and produced by validators are actually correct. And that, for example, you know, a staking pool doesn't collude to print itself a bunch of ETH. It is free to do that.

So, like, you can just download, you know, your consensus layer client, your execution layer client, and run that. It will sync to the chain. It will verify that the history of that chain, you know, the rules were followed. Or at least that there was, like, strong agreement amongst everybody that the rules were followed. And then today, you know, like once you are saying, every new block, it will run it and make sure that, like, every transaction in that block meets the rules of the protocol. And that's, like, really important. Because the only, the kind of biggest blocker that we have to validate those commuting and changing the roles of the protocols is having a large number of nodes that are run by non-validators who just like act as a check and make sure that they're not changing the rules of the protocol behind closed doors. So if you run a node, you do contribute to the security of the network.

You don't have to put up capital to do it. It's a public good then to run a note, a non-validating note. It's kind of like, you know, voting in your local election. is sort of a public good and a check on power. Yeah, that's correct. Tim, I know you already have a call that started two minutes ago. Thank you so much for coming in between a very busy schedule of your day. The last misconception, you can drop off whenever if you do need to run.

The last misconception I'll bring up is that in the post-merge world, the eat stake rate is going to be something like 15%. That number has now, well, no one really knows that number, but like new consensus on very, very informed individuals like Polynia have converged around 7%. And so the current ETH stake rate is like something around

4. something percent is going to go up to 7-ish percent, give or take, post-merge, not in the teens at all. Tim, thank you so much for coming on bankless and giving us all of this clarifying information

and allowing us to ask when merge in 50 different ways. Of course, thank you so much for having me. Yeah, have a good one, guys. Bye, Tim. There you go, guys. Some of the misconceptions

just to clear up. So you can't withdraw your staked eph after the merge. Number one, the merge will not lower transaction fees. If you've been told that, that's incorrect. The merge actually will decrease eith issuance. So if you've heard it's increasing eth issuance that is incorrect. Users and apps will not have to do anything when they upgrade. You still can, as you can with Ethereum right now, run a node without staking. In fact, it is a public good. to run a node because it is a check on power that is essentially how we're voting in these blockchain systems and the last one david what's that about the eith stake rate it's actually more like 7% is rather than 13% or so does that count does does is mv included in that figure david

is included in that figure uh the 13 to 17% east stake rate came on the assumption of a 70 30 block fee to tip uh ratio uh in at post eip 1559 your transaction fee is split into two halves. One half is the base fee, which people thought was going to be about 70% of the total transaction fee, and 30% would be the remainder tip. Now that EIP-159 has been live for a while, we have much more data, we've noticed that these numbers have converged on at 90-10. So 90% of your transaction fee gets burnt. Only 10% goes to the validators. So that brought the e-stake rate down a little bit. And then the other half of the story is that, well, when we first started talking about ultrasound money and the east stake rate, it was in the middle of defy summer when like gas fees were like two to 400 guay consistently.

And now instead they're like 20 to 40 guay. So that also brought the east stake rate down. And so that went from like these very, very high, high number estimates of something like 13 to 17% down to a much more much more like kind of logical and reasonable number of 7%. However, that does not mean to say that if the gas fees to go back up, the east stake rate would also go back. up. I don't even, it's very hard. It's like I guess what we're doing is we're just picking another point in time and crafting a prediction based on the market conditions right now and saying it's lower than 13% because it's a different market conditions. But obviously so many supply demand dynamics go into that rate, including how many validators are part of the network, right?

And so this will all fluctuate. But it's likely over the long run that we'll see, you know, between 4% and then at times into the double digits percent for the ETH stake rate. And that will fluctuate over time as well. The other point is really interesting is so EIP is actually burning more than we thought it is. That's still very good for all Ethereum holders, of course. So that value just accrues to anyone who holds Heath rather than just the validators. So you know 90% is burnt. It's actually a pretty surprising number to me, but that has certainly been the case with the IP 1559. David, we should-

Before layer twos start sucking up all the block space. They're only like at 3% now. One day there'll be a 3%. One day, Ryan, they'll be at 90%. And gas speed will be extremely high. True, true, true. All right, man. So we got our answer, I think, when merge. We're doing dress rehearsals right now.

Merge in, you know, two to five months or so. Before the end of the year, it's got to happen. So we are close. And David and I will be continuing to sit in the backseat with the bankless nation, asking everybody involved when merge? As the weeks go by and the months progress, but we are getting very. very close folks. Anything else you want to end on, David? The thing I want to end on is, if you like this video, the merge will come faster. It's a verifiable fact. So if you're watching

on YouTube, go ahead and click that like button. I see a 420 people watching it, and I only see 141 likes. So y'all got some work to do. And while you're at it, you might as well hit that subscribe button as well, because if you subscribe to bank lists, you subscribe to when merge updates. And so every time we ask when merge, you will hear the answer as we get closer and closer and closer to that. Thank you, everyone for tuning into bankless. And I guess if you're listening on the podcast, go ahead and give us a five-star review as well, because, again, the more that bankless here gets to more ears, the more the

bull market gets returned to our hands. I like when you say things like this, David. Yeah. I'm insented. I'm going to go review this podcast. It sounds great. Let's save us from the bear market. Risk and disclaimers, of course, as always, guys, none of this has been financial advice.

It's not e-th-merge advice. We don't honestly know a date yet. but hopefully we will soon. Eat this risky. A TDD. We want a TTD. A TTD. As is all of crypto, you can definitely lose what you put in. But we are headed west. This is the frontier. It's not for everyone, but we're glad you're with us on the bankless journey. Thanks a lot.