Dencun 101: Tim Beiko Explains Ethereum’s Upgrade and Beyond

Ethereum's next hard fork is here and we're joined by Tim Beiko from the Ethereum foundation to walk us through and explain what it all means. He shares a comprehensive guide on each and every EIP along with what comes next, Dencun, Pectra, and beyond. If you want to be up to date with the state of all things Ethereum this is the episode for you. ------ 🏹 USE PODCAST24 FOR 10% OFF https://bankless.cc/Citizen2024 ------ 🎧 Listen On Your Favorite Podcast Player: https://bankless.cc/Podcast ------ BANKLESS SPONSOR TOOLS: 🐙KRAKEN | MOST-TRUSTED CRYPTO EXCHANGE https://k.xyz/bankless-pod-q2 ⁠ 🦄UNISWAP | SWAP SMARTER https://bankless.cc/uniswap 🔗CELO | CEL2 COMING SOON https://bankless.cc/Celo 🗣️TOKU | CRYPTO EMPLOYMENT SOLUTION https://bankless.cc/toku 🛞MANTLE | MODULAR LAYER 2 NETWORK https://bankless.cc/Mantle ⚖️ARBITRUM | SCALING ETHEREUM ⁠https://bankless.cc/Arbitrum https://%E2%81%A0https//bankless.cc/Arbitrum ------ TIMESTAMPS 00:00 Start 04:44 Naming "Dencun" 08:40 Overview on Blobs 11:31 EIP-7514 (Epoch Churn Limit) 14:42 EIP-6780 (Self Destruct) 19:27 EIP-7044 (Signed Voulentary Exits) 20:49 EIP-7045 (Max Attestation Inclusion) 21:49 EIP-4788 (Beacon Block Route) 25:31 Opcode Changes 29:58 What's Next 37:53 Future EIPs 41:37 Max Effective Balance 45:22 Inclusion Lists 50:40 Additional Noteworthy EIPs ------ RESOURCES Tim: https://twitter.com/TimBeiko ETH Magicians: https://ethereum-magicians.org/u/timbeiko/summary ------ Not financial or tax advice. See our investment disclosures here: https://www.bankless.com/disclosures⁠ https://www.bankless.com/disclosures%E2%81%A0

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00David Hoffman?

  The way I've been explaining this is like we are getting Stone Age blobs with Dencun 4844, but then the blobs can evolve into like sci-fi blobs independently of any sort of Hard Fork. And so the blobs are going to be able, is that true?

• 0:18David Hoffman?

  Welcome to Bank List, where we explore the frontiers of Ethereum. Today on the show, I brought on Tim Baker. It is Hard Fork Day. It's either today or tomorrow, depending on when we release this episode. Dencun is here, the blobs have arrived. We unpack what is beyond the blobs in this episode with Tim Baker, however, because there are other EIPs after EIP 4844 that are going into Dencun. And then there are all some EIPs that did not make it into Dencun that will come in the next Hard Fork, which is Pectra. And then after Pectra, there are going to be further EIPs. And so Tim Baker on the episode today walks us through all the EIPs that are coming now, coming soon, and coming later. So if you want to really dive into the 300 level, 400 level,

• 1:00David Hoffman?

  decently technical future of Ethereum, this episode is for you. Emphasis on this being a pretty technical nerdy episode, really for the people who are like, you know, listeners of the Daily Guey, Ethereum core devs, you know, people who have been, want to explore the bottom depths of the Ethereum rabbit hole. This episode is for you. Bank Listation, we're going to get to our conversation with Tim Baker right now. But first, a moment to talk about some of these fantastic sponsors that make this show possible. If you want a crypto trading experience backed by world-class security and award-winning support teams, then head over to Kraken, one of the longest-standing and most secure crypto platforms in the world. Kraken is on a journey to build a more accessible, inclusive, and fair financial system, making it simple and secure for everyone, everywhere, to trade crypto.

• 1:43David Hoffman?

  Kraken's intuitive trading tools are designed to grow with you, empowering you to make your first or your 100th trade in just a few clicks. And there's an award-winning client support team available 24/7 to help you along the way, along with a whole range of educational guides, articles, and videos. With products and features like Kraken Pro and Kraken NFT Marketplace and a seamless app to bring it all together, it's really the perfect place to get your complete crypto experience. So check out the simple, secure, and powerful way. For everyone to trade crypto, whether you're a complete beginner or a seasoned pro. Go to kraken.com/banklist to see what crypto can be. Not investment advice. Crypto trading involves risk of loss. Cello is the mobile-first, EVM-compatible, carbon-negative blockchain built for the real world, driving real-world use cases like mobile payments and mobile DeFi.

• 2:27David Hoffman?

  And with Opera Mini Pay as one of the fastest-growing Web3 wallets, Cello is seeing a meteoric rise with over 300 million transactions and 1.5 million monthly active addresses. And now, Cello is looking to come home to Ethereum as a Layer 2. Optimism, Polygon, Matter Labs, and Arbitrum have all thrown their hats in the ring for the Cello Layer 2 to build upon their stacks. Why the competition? The Cello Layer 2 will bring huge advantages, like a decentralized sequencer, off-chain data availability secured by Ethereum validators, and one-block finality. What does that all mean for you? With Cello Layer 2, gas fees will stay low, and you can even pay for gas natively using ERC20 tokens, sending crypto to phone numbers across wallets using social connect. But Cello is a community-governed protocol. This means that Cello needs you to weigh in and make your voice heard.

• 3:11David Hoffman?

  Join the conversation in the Cello forums. Follow Cello on Twitter and visit cello.org to shape the future of Ethereum. Are you launching a token? Is it already live? How are you managing the legal and tax obligations for providing token grants to your team? It's no secret that token management gets complicated. Between learning all the legal language and tax obligations in every country that your team is in, token grant management can feel like an obstacle course. But it doesn't have to. That's where Toku steps in. Toku provides practical tools to handle token grants, allowing for effective oversight of token distributions and payroll tax compliance for employees, contractors, advisors, and investors. They also handle tax withholdings through their real-time tax calculations that can be done by Toku or integrated into any payroll EOR providers in any jurisdiction. Toku is a trusted provider of protocol labs,

• 3:57David Hoffman?

  DYDX Foundation, Mina Protocol, and many more. Get started for free and make token compensation simple at toku.com/banklist. Banklist Nation, I'm here with Tim Baker, the coordinator at the Ethereum Foundation, leads the all-core dev calls. Tim, how you doing? Good. Thanks for having me. Yeah, exciting times in Ethereum. We are the week before the hard fork. We'll actually air this either the day before or the day of the hard fork. So happy hard fork day for everyone listening. Tim, I want to go through Dankun and the high-level EIPs. We'll just talk about, we'll just run through all of them just to really unpack what's going on in Dankun. And then we'll talk about what didn't make it into Dankun, which is, which means like, what are the EIPs still in the all-core devs mem pool that we know we want?

• 4:40David Hoffman?

  Eventually included, just didn't make it into this particular hard fork. Sounds good?

• 4:43Speaker 01

  Yeah.

• 4:44David Hoffman?

  Cool. But before we do that, can we actually talk about the whole naming convention thing? Dencun is a weird word. I don't think it's a word. The next one after this is Pectra or Electra, maybe. Can we talk about how the naming convention works on these hard forks? Like, what does Dencun mean? How did it come to be?

• 5:01Speaker 01

  Yeah, that's a good place to start. So on Ethereum, you know, before the merge, we had both the proof-of-stake chain and the proof-of-work chain sort of updating independently. And both of those sides had like a different naming scheme, you know, to name upgrades. So on the proof-of-work side, we started, we had, you know, like Frontier, Homestead, Metropolis. And then for a couple of years, we just used variations of Istanbul city names. So Byzantium, Constantinople, and Istanbul. And then we sort of ran out, so we started using Dencun city names. So then we had the Berlin hard fork, or Berlin hard fork London, just following the Dencun city orders.

• 5:43Speaker 01

  And so now we're up to Cancun, just following Dencun city names. And we had a little, actually, exception there. We called the merge Paris as a shout-out to ECC, which was a big, the first big community-hosted conference. So we use those to specify the names for the execution layer upgrades. On the consensus layer, though, they liked using stars instead. So they use the name of stars and they go alphabetically. So the first one was called Altair, then it was Bilatrix, and then Capella, and now Deneb. But in practice, if you're just like an Ethereum user, the execution and consensus layer upgrade happens at the same time. There's like different code on both sides. So we need like different name

• 6:24Speaker 01

  to refer to like the actual changes to the proof of stake side of thing, the actual changes to the EVM. So we use like Cancun and the neb to refer to those, you know, sub changes. But because the upgrade all activates at the same time, we decide to mash those names together. So we have dencoon, which is a mash of the neb and Cancun. And then the previous fork, Chappelle was a match of Shanghai and Capella. So yeah, we've been using these. And in the future, if we had a fork that was like just one side of the chain, then we probably just use like a city name or a star name. But when they happen together, yeah, we we couple the names.

• 7:03David Hoffman?

  Okay, so it is actually possible to fork the consensus layer and not the execution layer?

• 7:08Speaker 01

  Yeah. And in practice, the fork basically happen independently. So we tell the consensus layer at this epoch, you know, fork, we tell the execution layer at this timestamp fork, and the timestamp just happens to be the same as, you know, the epoch start time. But there's no, there's no, you know, like, reason for them to like have to fork and lockstep. And we want to preserve this because imagine there's just like a bug in the EVM that we find tomorrow, we can just ship a hard fork on the EVM and the consensus layer doesn't need to know about it and vice versa. Yeah.

• 7:45David Hoffman?

  Okay, but but the people who are running the CL and the EL, the consensus layer and the execution layer are the same people for the most part.

• 7:53Speaker 01

  Yes. Yeah, yeah, correct. So like if you run a validator, you run a node, like you, you have to run both, but it's just, and and in this hard fork, you need to upgrade both. But there's no, there's no, there's nothing that forces both to have to be upgraded. So if say we had an emergency hard fork on the consensus layer, we could have an an update just saying like, look, upgrade your consensus there node, your your execution layer node is fine.

• 8:19David Hoffman?

  Beautiful. Okay. All right. So that gets the naming out of the way. Now, because we have the CL and the EL combined, we have earthly cities and astral stars being portman-toed into the same word. And so that's how we came up with Dencun. And then Pectra is the next one?

• 8:36Speaker 01

  Yes. So Prague and Electra have been merged into Pectra. Yep.

• 8:40David Hoffman?

  Okay. Beautiful. All right. So Dencun is known as the Blob Hard Fork, the Hard Fork that we get the blobs. EIP 4844. It's a cool one that gives Ethereum its own enshrined data availability layer. We've talked about blobs on bank lists. We've had entire episodes dedicated to blobs. Listen to our episode with Domethy about blobs if you really want to dive into blobs specifically. I don't think we really need to dive into that one because we've covered it so extensively before. But Tim, like since we're so close to the Hard Fork Day, like what do you want to elevate about blobs? People are like speculating about like gas fee reductions on Layer 2s, but I know we don't really know. Is there anything before we move beyond blobs that you want to talk about?

• 9:20Speaker 01

  Yeah, we did talk a lot about them. I think the one thing I'll say is what's neat about this upgrade is it sort of sets the stage for full dank sharding after. So you can think of this upgrade as like almost the front end to blobs where we have all the new sort of infrastructure and scaffolding that the network needs to use them. So we have like a new transaction types which L2s can like migrate to to use it. And then in the future, when we have more scaling capabilities with stuff like full dank sharding, we can just do that in the background and L2s will not have to like upgrade. There'll just be like more blob space that they can access on the network. So I think that's like a really cool thing where, you know, all the L2s have to like do work to support this now.

• 10:05Speaker 01

  And they've all like done it and are in like the final stages of testing. But hopefully, you know, they never have to do anything again that like support blobs. And, you know, there just ends up being more blob space coming on. So I think that's something that's like not discussed enough where, yeah, we really set like the entire architecture now. And we can just keep expanding in the background.

• 10:28David Hoffman?

  Right. The way I've been explaining this is like, we are getting Stone Age blobs with Dencun 4844, but then the blobs can evolve into like sci-fi blobs independently of any sort of hard fork. And so the blobs are going to be able, is that true?

• 10:44Speaker 01

  Depending on how you approach it, you might need a hard fork, but it's more that the, even if there is a hard fork, the L2s won't have to do anything. Like, so for now, they post their, they post their data and call data, so they have to switch, you know, the type of transactions that they make. But in the future, when we have more blob space, the blob transactions of like next week will still be valid and will like integrate with all that automatically.

• 11:10David Hoffman?

  Right. Okay. So the future call data, which we call blobs, is just going to be able to fit more stuff without, and the Layer 2s won't really care about like how, how big they are. They will be able to leverage them all the same.

• 11:21Speaker 01

  Correct.

• 11:22David Hoffman?

  Yeah. Okay. All right. So that's blobs. We'll actually talk about PeerDAS, which didn't make it into Dencun. We'll talk about that towards the end of the show, but this is like one of these like blob evolutions, blob blutions. Max, add max epoch churn limit. That's EIP 7514. That's also coming into Dencun. What should we know about that?

• 11:42Speaker 01

  Yes. So right now on the beacon chain, when validators come in, the amount of new validators that can start validating per block is a function of how many validators are already there. So as more and more validators come in, we accept more and more each block. And the reason, you know, for that change originally was just, you don't want to like overwhelm the validator set with new validators in case of like an attack or something. But as you have a bigger and bigger validator set, you can sort of bring more people in quicker.

• 12:16David Hoffman?

  That said, just to state that really simply, the size of the rate of change of validators is a function of the total size, total supply of validators.

• 12:28Speaker 01

  Correct. Yeah. Active validators. Yeah.

• 12:31Speaker 01

  And this effectively since the launch of the beacon chain has been like up only because there's been more and more validators and we've like so there's more and more validators and we've therefore accelerated the rate at which we add new validators. Recently, I don't know, in the past year or so, there's been a lot of like discussion and debate around, you know, should there be a max amount of validators on the network? And does the even at the current rates of growth, is the amount of validators going to end up being too much in terms of like the amount of messages that they gossip on the network and sort of the requirements that that implies in terms of bandwidth?

• 13:16Speaker 01

  So the idea with this proposal is that instead of making the number of validators each block a function of how many validators are there, we simply cap it at eight per block. So we have that as a ceiling. And this basically slows the rate of growth and it one lets client teams deal with like the increase in validator set size so that they can, you know, have a bunch of performance improvements and whatnot to deal with that. And two, it sort of lets the entire community have a discussion around like, okay, what's like the right share of validators that we'd want to have on the network? And ideally not end up having that discussion in a world where like, I don't know, say

• 14:00Speaker 01

  we decided we never want more than 50% of eat to be staked for whatever reason, but then there's already two thirds of the eat staked. That's kind of an awkward place to be in. So this just gives us a bit more breathing room to figure out the right path forward.

• 14:14David Hoffman?

  Okay, so there is going to be a cap so on the rate of change. And when is that cap hit?

• 14:22Speaker 01

  So it's we're already, I don't know if we're past it already, but we will be at like at the hard fork, the cap will be eight, basically.

• 14:29David Hoffman?

  Okay. Okay. So eight validators per block, eight times 32 ETH per block is the constraint. And the idea is that just we just want to, we want to buy us buy ourselves some time before Ethereum discovers its long-term equilibrium with E stake.

• 14:42Speaker 01

  Yeah, correct.

• 14:43David Hoffman?

  Cool. Okay. Awesome. Self-destruct only in the same transaction, EIP 6780. What does this do? Self-destruct has always been one of these like weird words that I see every now and then. People have like strong feelings about it. What's self-destruct and why? What is this EIP doing?

• 14:58Speaker 01

  Yes. So self-destruct is pretty straightforward. It's how you can delete a contract from Ethereum. So you have to specify this in advance, but like if you want your contract to destruct, there's this op code which will delete it. And the rationale for this op code was that if we want people to like clean up after themselves, you know, it's nice to give them a mechanism to do it. In practice, though, it hasn't been used much for that. It's been used in a bunch of like really weird funky ways, but it's it's not something that's like keeps Ethereum state size, you know, smaller than it it should be.

• 15:37Speaker 01

  So, um, so, so like, yeah, the, the value of the op code is, is, is not like, uh, what sort of we expected in terms of the protocol. And the, the biggest problem with self-destruct is it's the only op code where when you call it, you don't know how much computation you're going to run. So if you call self-destruct on like a tiny contract, um, self-destruct gets the address passed in as a parameter, and then it sort of finds this address and deletes everything that's there. So if it's a small contract, that's super quick. But if it's like a huge contract, imagine you called it on like some massive NFT contract with like millions of balances. Then it's like, in that same amount of time, you now have to delete all of this.

• 16:17Speaker 01

  And maybe an analogy is, you know, on your computer, when you move a file to the trash, it's sort of instant. But if you delete like a thousand pictures, you know, it says like moving them to the trash and it's like loading. So self-destruct has like that behavior. Um, and that's bad for Ethereum because it, we want like the gas that we charge for op codes to reflect the cost of computation. And for this one, we sort of can't. And now it's kind of bad, but not the end of the world because of how Ethereum is structured. But we have this long-term goal to move towards stateless clients. And this requires changing how we store data on Ethereum. And by virtue of like how we change that self-destruct, that becomes like insanely long to run every single time.

• 17:02Speaker 01

  We just can't like afford that. Yeah. Um, so basically removing it is the first step towards that. And so what this EIP does is when you call self-destruct, it will not destroy the contract anymore, but it'll still send the money back to like the address you specify. So this is the other thing that self-destruct does. If you delete a contract, you get to say where to send the money. Obviously, we don't want anybody's funds to be trapped. So when you call self-destruct after the fork, all it does is it transfers the ETH in that contract, but it doesn't actually destroy the contract. And that said, there are people who use self-destruct in a bunch of really weird ways.

• 17:42Speaker 01

  And one of those edge cases is sometimes people will like create a contract and destroy it in the same transaction. Sometimes they do that to burn some ETH. I believe that's how optimism, those like withdrawal bridge works. It'll like create a contract with some ETH in it and then self-destruct it and send the ETH to zero, address zero or something. And that's like their weird trick to make it work. Um, and those cases we can still support because you don't actually have to write this contract to disk. Um, because it's all in the same transaction that it's happening. So this is why the EIP has like a super long name. It's like, okay, we managed to get the functionality that we want to be like deactivate it. But then we get to preserve this edge case, which was relied upon in a lot of like critical flows. So no contracts break. Yeah.

• 18:28David Hoffman?

  Interesting. I sometimes when I talk to people like you about this, I like, once again, realize how deep some of these like technical like EIP rabbit holes go.

• 18:37Speaker 01

  And we've been trying to do this for years. So it's, it's nice to actually see a chip and to know that like, okay, we found like the sort of edge cases that we can handle and, and yeah, not break things.

• 18:47David Hoffman?

  And this is the final equilibrium of self-destruct. This is the last EIP that self-destruct will be relevant or?

• 18:54Speaker 01

  Yeah, I think so. Um, I mean, it's hard to predict the future, but I think it does everything we want at this point.

• 19:00David Hoffman?

  Okay, cool. So we're confidently putting it on the shelf. Maybe we pull it off, hopefully not.

• 19:05Speaker 01

  Yeah, yeah, like, yeah, yeah. So we always have to preserve this property of like sending people's money back because if imagine you had a contract that you thought you were going to self-destruct in a year and there's a tons of ETH in it. Like, we can never stop you from getting that ETH back. So like, that functionality will always stay there.

• 19:23David Hoffman?

  Okay, so this is minimum viable self-destructive.

• 19:25Speaker 01

  Yeah, yeah.

• 19:25David Hoffman?

  We've discovered ourselves. Okay, cool. All right, moving on. Perpetually valid signed voluntary exits. I'll say that again. Perpetually valid signed voluntary exits. EIP 7044. What's this?

• 19:36Speaker 01

  Yes, so on the beacon chain, you can pre-sign an exit message. And up to now, I don't know why I wasn't involved in that design, but like, these messages were only valid for like the next two hard forks, I think. And this is, and I guess, you know, again, I'm not sure why they made that decision at first. But in practice, it turns out like people use these messages today to build like trustless staking constructs where imagine I'm like a staking operator for you and you want to always be able to withdraw your funds. What I can do is I can sign an exit message with your validator, give it to you. And then if I start doing something badly, you can just go and publish that message and your validator gets exited.

• 20:21Speaker 01

  And you don't need me to like do that for you. The problem with that with the current messages is it only lasts two hard forks. So you need to like trust that I sort of give you a new one every hard fork or something. So it doesn't expire. So this EIP just makes a small change to make those messages valid forever. And it can, it can allow you, it can allow you to have like a one-time sign message where, okay, you receive this. You know, you can always exit your validator, even if you're not the one operating it.

• 20:46David Hoffman?

  Okay, seems pretty straightforward.

• 20:48Speaker 01

  Yeah.

• 20:49David Hoffman?

  Yeah, all right. EIP 7045, increase max attestation inclusion slot. Oh, boy.

• 20:56Speaker 01

  This is like the most technical beacon chain EIP. You know, he shot Danny Ryan on the show and he can tell you all about it. But TLDR is it just increases effectively the max distance that you can include an attestation for in your, in your block. There is some security rationale for this, which again, proof of stake researchers can get into. As a user, as a validator, this all just happened automatically. It just changes like how far you go when you're looking at including attestation.

• 21:28David Hoffman?

  So if you're in a test or you just have more time, you have more space to attest?

• 21:32Speaker 01

  Yeah, correct. No, sorry. So if you're collecting attestations from other people, you can collect them farther. So it means that the like first attestation of an epoch basically gets like twice as long of a valid period it can be included for. Yeah.

• 21:49David Hoffman?

  Okay. All right. This one's pretty cool. EIP 4788 beacon block root in the EVM. So beacon block, that means we're talking about the beacon chain. The root of that block is going into the Ethereum virtual machine. So this one is spanning the consensus and the execution layer, correct?

• 22:06Speaker 01

  Correct.

• 22:07David Hoffman?

  What's going on over here?

• 22:08Speaker 01

  Yeah. So today, we have, you know, ever since the merge, both chains run alongside each other. But there's no ways to make proofs about the state of the beacon chain on the execution layer. So in a smart contract without an external oracle. So if you want to say like, you know, this was the state of the beacon chain at like slot X, you have to rely on an external oracle, which is not great. So what this does is it creates a new contract on Ethereum where every block, we just store the latest block hash for the beacon chain blocks and have the header there so that you can trustlessly make proofs against it. So this is really helpful for like a bunch of, say, staking pools that want to make proofs about like the current state of the beacon chain and whatnot,

• 22:52Speaker 01

  and not have to rely on an external oracle. So it just makes, yeah, a bunch of like, yeah, constructions more trustless.

• 22:59David Hoffman?

  Yeah. So this connects, this is actually, I think, one of the, one of the big, I'm going to make this the second biggest EIP inside of this hard fork after 4844, mainly just because like it connects DeFi, Ethereum's DeFi application layer to the Ethereum consensus proof of stake staking layer.

• 23:15Speaker 01

  Yeah.

• 23:15David Hoffman?

  And so you said like staking pools, like this affects the Rocket Pool O Dow node. There's this small Dow inside of the Rocket Pool system that connects basically this information, the state of the Ethereum consensus layer and the ETH in the staking contract to Rocket Pool. This also is helpful for Eigenlayer and AVSs because they need to know the state of ETH on the beacon chain so that, you know, when AVSs make a slashing event and the slashing event occurs, other AVSs can know about it.

• 23:47Speaker 01

  Yeah. Yeah, yeah, basically it removes any sort of oracle risks around that information. Whereas now, all of those projects have to trust some oracle to tell them what's up on the beacon chain.

• 24:00David Hoffman?

  Yeah, Vitalik actually put out a recent tweet about how he was like having a change, not like a wholehearted like 180 pivot change of mind, but like a change of mind about like complexity at the layer one, where he's saying like, oh, I used to be like a layer one complexity minimalist. And now I've become like a little bit more into the idea of complexity inside of the layer one, because it reduces complexity at the layer two. And I see this as an example of it. What we are doing, what the Ethereum layer one is doing here is enshrining an oracle. It's producing an oracle inside of itself, like it's taking on more roles, so that less roles can happen at the execution layer.

• 24:39Speaker 01

  Yeah, yeah, and yeah, 100%. And I think this one is nice because it's not very complex, because L1 already has this information, it's just like on the wrong side of the chain. And then, every block, the beacon chain already passes information to the execution layer. Like every time you get a new block, your validator asks your execution engine, like, is this a valid block? And so they're already talking every block, so it's just like adding one more bit of data, and then having the execution layer like save a copy. And then, yeah, that has a huge impact in terms of like creating like a more trustless source of information on chain.

• 25:18David Hoffman?

  Yeah, really, I just like the idea of just like a stronger bridge between the state of the consensus layer and the state of the execution layer.

• 25:26Speaker 01

  Yeah, yeah.

• 25:27David Hoffman?

  Beautiful. Okay, there's three minor ones that we're just gonna burn through really, really quickly. 1153 transient storage opcodes, 5656mcopy, memory copying instruction, and then 7516 blob base fee opcode. What's going on here?

• 25:42Speaker 01

  Yeah, maybe to start from the last one, because it's simplest. So blob base fee, we have this opcode on chain to get the base fee for gas. And it's useful if you want to do things like, imagine an L2 that wants to reimburse people's gas when they submit a fraud proof. They can just say, you know, send them blob base fee times, you know, like the gas that they spent. So they can have that all trustless on chain. Now that we have blobs, you want to have an opcode to get the blob base fee. So pretty straightforward to expose that. MCopy is just a memory copy in the app code within the EVM. So if you're very much into like language design or EVM optimization, it gives you a bit more, a bit more options.

• 26:25Speaker 01

  And then 1153 has two new app codes, TStore and TLoad, which are storage app codes that disappear at the end of a transaction. So right now, when you save data on Ethereum or read data from Ethereum, it sort of is there forever and you have to read the disk, which is more expensive. So with transient storage, you just keep those in memory, delete them at the end of the transaction. And so it's cheaper, yeah, cheaper to execute. And therefore the gas price is lower.

• 26:56David Hoffman?

  Mantle, formerly known as BitDow, is the first DAO-led Web3 ecosystem, all built on top of Mantle's first core product, the Mantle Network, a brand new, high-performance Ethereum Layer 2, built using the OP stack, but uses Eigenlayer's data availability solution instead of the expensive Ethereum Layer 1. Not only does this reduce Mantle Network's gas fees by 80%, but it also reduces gas fee volatility, providing a more stable foundation for Mantle's applications. The Mantle Treasury is one of the biggest DAO-owned treasuries, which is seeding an ecosystem of projects from all around the Web3 space for Mantle. Mantle already has sub-communities from around Web3 onboarded, like Game7 for Web3 gaming and Bybit for TVL and liquidity and on-ramps. So if you want to build on the Mantle Network, Mantle is offering a grants program

• 27:39David Hoffman?

  that provides milestone-based funding to promising projects that help expand, secure, and decentralize Mantle. If you want to get started working with the first DAO-led Layer 2 ecosystem, check out Mantle at mantle.xyz and follow them on Twitter at @zeroxmantle. Arbitrum is the leading Ethereum scaling solution that is home to hundreds of decentralized applications. Arbitrum's technology allows you to interact with Ethereum at scale with low fees and faster transactions. Arbitrum has the leading DeFi ecosystem, strong infrastructure options, flourishing NFTs, and is quickly becoming the Web3 gaming hub. Explore the ecosystem at portal.arbitrum.io. Are you looking to permissionlessly launch your own Arbitrum Orbit chain? Arbitrum Orbit allows anyone to utilize Arbitrum's secure scaling technology to build your

• 28:23David Hoffman?

  Own Orbit chain, giving you access to interoperable, customizable permissions with dedicated throughput. Whether you're a developer, an enterprise, or a user, Arbitrum Orbit lets you take your project to new heights. All of these technologies leverage the security and decentralization of Ethereum. Experience Web3 development the way it was always meant to be: secure, fast, cheap, and friction-free. Visit arbitrum.io and get your journey started in one of the largest Ethereum communities. Uniswap is revolutionizing the DeFi space, not just by enabling swaps, but by empowering you to swap smarter with a comprehensive suite of products for faster, safer, and more informed swapping. Say goodbye to pop-up wallet extensions. The Uniswap extension is coming soon, and this extension is not a pop-up. It is a sidebar in your browser that persists no matter where you are on the web.

• 29:07David Hoffman?

  This means you can swap, sign, or send, and receive crypto anytime, anywhere, without obstructing your browser window. But that's not all. The Uniswap web app now features limit orders, so you can buy and sell any token at your price, on your terms, without having to watch the market. And the best part: limit orders are built on Uniswap X, which means no gas fees. Also new to the web app is the data and insights pages, with real-time candlestick charts, price data, transaction logs, and detailed pool data, all integrated into the Uniswap web app. All of these new releases come together to create one platform to help you swap smarter every time, no matter where you are: on web, mobile, or on the extension. Click the link in the show notes to sign up for the extension waitlist and download the mobile app. Start swapping smarter with Uniswap. All right, well, round of applause for all of our EIP finalists that made it into Dencun.

• 29:52David Hoffman?

  Congratulations for all the EIPs that made it in there. There are some EIPs that did not make it in there. Which are the ones that got rejected? Which are the ones that didn't make it into the gate that are worthy of note?

• 30:04Speaker 01

  So there's a lot, to be clear.

• 30:05David Hoffman?

  Yeah.

• 30:06Speaker 01

  We have a whole Ethereum magician's thread where people propose them. There's probably like 20, 30 proposals, and we can include maybe something like eight. And then...

• 30:15David Hoffman?

  So this is like the EIP mempool. And so Dencun is the block that was formed, which is going to be merged into Ethereum. And so we have like seven, or eight, or nine EIP transactions that are being merged.

• 30:29Speaker 01

  Yes.

• 30:29David Hoffman?

  But the rest are still in the mempool. And so the next hard fork is going to be Electra. What are the names for, what are the two names for Electra again?

• 30:37Speaker 01

  Prag and Electra, so Pectra.

• 30:38David Hoffman?

  Prag and Electra.

• 30:39Speaker 01

  Pectra is the merge name, yeah.

• 30:40David Hoffman?

  Pectra is the merge name, yeah, the portmanteau name. And so like, still kind of like finding its identity, right? Like, we don't, right now, zero EIPs are formally in Electra, right?

• 30:50Speaker 01

  We have a few, actually.

• 30:51David Hoffman?

  Oh, really?

• 30:51Speaker 01

  Yeah.

• 30:52David Hoffman?

  Okay, sure.

• 30:53Speaker 01

  And maybe, yeah, to zoom out a bit. So over the past couple of years, we've sort of moved to this cadence where we have one big fork, one small fork. So we, we had the merge, which was obviously like a huge fork. And then we had withdrawals right after, which was a bit of a smaller one. And now we have Forge 4.4. And so Big one. Yeah, another big one. So for Pectra, we're, we're planning to do a bit of a smaller fork and to start working on the next larger fork in parallel, kind of like we, we've done with this one. So we've been working on Forge 4.4 for like probably two years at this point. And then in parallel, we were able to ship withdrawals as well. So Pectra is going to be a smaller fork, but we already have like a decent idea of what the bigger forks after that will be.

• 31:39Speaker 01

  Okay. So on the execution layer, we'll, we'll be up to Osaka at this point. We have this transition to Verko trees, which we've talked about a lot, which changes all of Ethereum's like storage layout for the state. So that's the thing that we're going to do like two forks from now and we're starting to work on right now. But because there's like so much work on it, there is like, and you can't have everybody just working on the exact same pieces of code. We do have some extra bandwidth to do another fork before. And then similarly on the consensus layer, they're working on effectively like full dank sharding. And there's a bunch of proposals around how to get there.

• 32:20Speaker 01

  Again, that's going to take some time. So they also have the bandwidth to do like a smaller fork in the meantime. So this is what Pectra will be. And it seems like maybe the forks after Pectra will actually be separate because it seems like the big thing we're doing on the execution layer, Verko trees is pretty independent from the big thing they're doing on the consensus layer. Maybe we'll end up with an EIP that we add as well that, you know, forces both to be together. But we sort of moving to this regime where like, we have like these two big initiatives happening in parallel. And then in the meantime, we're also trying to, to ship a bunch of like smaller, but still useful things.

• 33:00Speaker 01

  So for Pectra, we actually have four EIPs included already. So the BLS 12381 pre-compile. So this is something people have asked for since I think 2017, 2018, which is just using the same curve as the beacon chain as a pre-compile on the execution layer enables a bunch of use cases. So we're going to do that. And then

• 33:19David Hoffman?

  That's like, what that means is like the signing curve. So when we send a message. Yeah. And from what I understand, there are particular signing curves inside of like the the what are the enclave in your phone? Is this

• 33:33Speaker 01

  No, that's not. Yeah, no, that's not the one. No. What BLS is very good for, and the reason we use on the beacon chain is like aggregating a bunch of different signatures. So any use cases where like you have a bunch of different signature and you want to make a proof about like all of them and verify all of them. BLS is very efficient for that. And then if you want to verify signatures from validators, basically, you'll be able to do that.

• 33:56David Hoffman?

  Oh, this is the Justin Drake innovation that brought the minimum ETH stake from 1500 down to 32.

• 34:01Speaker 01

  Yes.

• 34:01David Hoffman?

  And so now we're now we're just taking that innovation down to the execution layer.

• 34:05Speaker 01

  And when we proposed, when it was first proposed in 2018, it was still kind of a new curve. There wasn't great like library support for it. So people were a bit reluctant to like add it to the proof of work chain. But now, you know, the entire beacon chain depends on it. Like if there's a bug in this, you know,

• 34:21David Hoffman?

  Ethereum already depends on it.

• 34:22Speaker 01

  Yeah. So it makes sense to just add it. So that's the first one we've included. Then the other big change that we're going to do is execution layer triggerable exits. So having a smart contract initiate, having a smart contract effectively initiate a withdrawal on the beacon chain. And again, this is valuable for a ton of like staking pools and whatnot where you'd want like any case where you want like a non-chain action to trigger a withdrawal, you can imagine like a DAO voting on it or, you know, stuff like that.

• 34:58David Hoffman?

  I would just say that all categorize that as further strong linkages between the DeFi layer and the consensus layer.

• 35:04Speaker 01

  Yeah. And that's like the theme. So another thing we're doing is basically

• 35:09Speaker 01

  removing the sort of delay period.

• 35:14Speaker 01

  So like right now, when you, when you make a deposit, when you make a deposit to the deposit contract, you still have to wait. I think it's like 2000 blocks for the deposits to be seen by the beacon chain. And this in proof of work, like before the merger was to avoid any reorgs. So we, you know, we were pretty confident there wouldn't be like a 2000 block reorg. And so the beacon chain, you know, once it saw 2000 blocks in the path that your deposit was in, it would credit you. But today they're like talking every block. So it's kind of useless to have this 2000 block. So we're removing that in Pectra as well. So it'll be just like the next block. And then there's another small, small proof of stake change that's been included.

• 35:56Speaker 01

  7549. I'm actually not too sure what that does. It's around like committee, committee attestations. So that's on the, on the proof of stake side. So we already have these four EIPs that are all quite small, but like, you know, pretty useful that are, that are included. Then we have these two big ones that are sort of, vertical trees is pretty much confirmed on the executioner side. I think how to approach dank sharding is still being like debated on a consensus there side. And, and you know, what's the right focus to have there. But we have like these two big things set for like the fork after that, a couple of small things now. And then there's also a bunch of other proposals which we can get into that we're trying to think through and figure out. Should it be in the next fork, the fork after and stuff like that.

• 36:38David Hoffman?

  Okay, so we get to Dencun like now, Elektra, call it a year, maybe less. Yeah, actually timing, timing on Elektra, nine months, 12 months?

• 36:48Speaker 01

  Um, look, it's really hard to predict these things. So I think

• 36:50David Hoffman?

  No, Dave, Tim, give me a day.

• 36:52Speaker 01

  Yeah, I think people would like to see it before the end of the year.

• 36:55David Hoffman?

  Okay.

• 36:55Speaker 01

  It's always nice to fork before Dencun and you come, you feel like you're, you know, you've done your job. And yeah, so, so we'll see. I mean, it, it depends on what we end up including in it, but like, the idea is to not spend like several years on that fork. It should be relatively

• 37:10David Hoffman?

  Of course. Of course. Okay. And so then, once we get past Pectra, then all of the ETH heads on Twitter are going to be like, "The Verge is coming, The Verge is coming." Because that's going to be like the next one. So we had EIP1559, The Verge. Now we have blobs, which we're getting. And then after that, we're all going to be stoked for The Verge. And for those who didn't listen to our episode with Mike Noyder and Domathie, The Verge kind of like increases the scalability of the Ethereum Layer 1 by about like 3X. A modest, but like, modest but like, you know, healthy increase. But really, it brings in statelessness, which makes Ethereum just like, super prolific, I'll call it. Like packets going between more devices relevant to Ethereum all over the internet.

• 37:53Speaker 01

  Yep.

• 37:54David Hoffman?

  Cool. But then there's also three EIPs that I know that are out there that I think are pretty damn meaningful that I want to get to before we wrap up this episode, Tim. Inclusionless, Max Effective Balance, and PureDAS. Where are these in the EIP mempool?

• 38:08Speaker 01

  So again, I'll start from the last. So PureDAS is like, one of the proposals for how we get the full dank sharding. So this is starting to be prototyped right now. And the idea there is, we have these, so these blobs give us like temporary storage on Ethereum right now, right? Where before the blobs, all the data that's stored on Ethereum has to be stored forever. It costs a lot of money to store data forever. The blobs allow you to store data for only a couple of weeks, but every node still has to keep a copy. So it's cheaper than like, nodes keeping a copy forever, but it's still every node keeps a copy. And the idea with full dank sharding is, we want to have nodes only store part of the data on the network.

• 38:51Speaker 01

  Where you store like, a bit of the data yourself, and then what you do is you ping the rest of the network, you ask them for proofs of data, and you do this enough times that you have like a high probabilistic guarantee that like... There's no data missing. The same way, you know, like when we use like hash functions, we trust that like a private key only maps to like a public key only maps to a single private key. And you know, the odds that like there could be a double match is like one in like two to the 256 or something.

• 39:21David Hoffman?

  Right.

• 39:21Speaker 01

  Um, so the idea with full dank charting is you basically do that as well, where you're saying like, I only have a small part of the data. I've asked everybody else in the network. And I've gotten, you know, this many responses and I know that like, given these responses, the odds that the data, that any part of data is missing anywhere is, you know, a really tiny probability. Um, and, and this, and if we can do this, then it means you go from like node storing all the data today, the nodes, all the data today forever, the node storing all the data for like a few weeks today to like, node storing only a part of the data for only a part of time. And this is how you can scale the number of blobs without scaling like the, the validator compute requirements.

• 40:02Speaker 01

  Um, so pure DAS is like a first proposal, um, or maybe not the first, but like one of the latest proposals to like, actually implement this based on the current like validator architecture. And so similarly to how people are starting to work on the verge and prototype that, um, we are starting to see people work on like pure DAS. Um, it's a bit earlier in development. So like, maybe that's not the final thing that we end up shipping. Um, but it's at least like a, a very promising step. Um, and I will say, uh, if you look on ETH research, Danny Ryan has like five ETH research posts that he's like authored. Every one of them has been like a shift in like the entire Ethereum roadmap, like sort of the, like, uh, the quick merge post and like the, the

• 40:45Speaker 01

  Vitalik wrote the rollup centric post, but then Danny wrote the like, how do we actually like implement this post? So like, Danny has like a really good hit rate with ETH research post. So, um, yeah, I don't know if like we'll ship pure DAS exactly as how it's specced, but, um, it seems, it seems very promising.

• 41:01David Hoffman?

  Cool. And of course, Pirdas is a part of the story of the evolution of blobs. These are like blobs growing up from little blobs to big blobs.

• 41:08Speaker 01

  Yeah, yeah, exactly. And it's not actually, sorry, just maybe to clarify this, it's not that the blobs are bigger.

• 41:15David Hoffman?

  But the total data availability is bigger.

• 41:18Speaker 01

  Yeah, there's just more of them, right? So you think of it as just like more blobs showing up.

• 41:24David Hoffman?

  Right. The blobs are actually getting smaller, but there's many of them. But when you aggregate all of those smaller blobs together, it becomes like big, big blobs.

• 41:31Speaker 01

  Yeah.

• 41:32David Hoffman?

  Many, many, many tiny little sharded blobs form big blob.

• 41:36Speaker 01

  Yeah.

• 41:37David Hoffman?

  These are technical terms. Max effective balance, Max EB, what does this do?

• 41:42Speaker 01

  Yes, so right now on Ethereum, you can only have a 32-bit validator, which, which, which causes like a couple of problems. Like, well, I guess maybe I'll start, what's simple about that is like we can treat all validators the same on the network, right? Like when we shuffle validators, they all have, we all treat them with like a 32-bit weight. And so you can like shuffle amongst.

• 42:04David Hoffman?

  One validator equals one validator.

• 42:06Speaker 01

  Yeah, exactly. But then the downside for that is twofold. One is we have these actors on chain that obviously have more than one validators, you know, staking pools, but even like a bunch of people have more than one validators. And every validator needs to send a bunch of messages over the internet. Like they all have to say like, oh, I attested to this or like I saw this and then send all those messages. And this creates a ton of bandwidth requirements. And right now I'd say like running a validator, you know, it takes maybe like two terabytes of disk space. It takes like a relatively recent computer, you know, like I could run one on my MacBook easily. But the biggest bottleneck is probably like bandwidth.

• 42:47Speaker 01

  Like it takes, you know, from like a couple of terabytes to maybe low tens of terabytes of bandwidth per month. And this is like something where, you know, a bunch, in a bunch of places, even if you can buy a MacBook and buy like a two terabyte hard drive, you maybe can't get like that much bandwidth. So the idea with Max EB is if we can tell people like, oh, you have 10 validators, you can put them together and then just sign like one message instead of 10, we can really lower the bandwidth requirement and that like. Makes it easier to run a validator. The other thing that's really nice with Max EB increase is it could potentially allow any amount of ETH sized validator. So that right now, the other disadvantage is you can only stake in 32 ETH increments. So say that I have like 50 ETH.

• 43:32Speaker 01

  Well, okay, I can stake 32, but then what do I do with my other 18 ETH? And this is the sort of thing that like drives people to like liquid staking tokens where it's like, I can get, you know, 50 ETH worth of like Rocket Pool staking tokens or Lido staking tokens and not have to think about that. So if we could move to a world where like, okay, I have an arbitrary number of ETHs that I want to stake. And then I can actually stake on like a reasonable internet connection because like we've, we've sort of aggregated these validators together. Um, yeah, that's a really positive thing for Ethereum. So, um, there's a ton of challenges in doing that. And this is why it's like not a no brainer to include it in the next fork. Like if it was easy, we, we probably would have done it already.

• 44:14Speaker 01

  Um, but it is being considered and, and we're trying to think about like, okay, are there like simplifications we can do in this spec? That like, maybe we get like a first version of it out in the next fork and like make it more complicated and, and, and provide more functionality in the fork after that. Um, so that's a, a big area of just like research and, and development right now.

• 44:33David Hoffman?

  Right. And it also allows solo stakers to compound their rewards. So 32 can immediately turn into 32.1, 32.3.

• 44:41Speaker 01

  Yeah, actually, yeah, that's a great point. Yeah. If you only have 32, then yeah, it would compound, yeah.

• 44:45David Hoffman?

  Right. And yeah, and so like rather, so like right, right now, when you have a 32 ETH, you get your ETH rewards, but they, they don't earn more rewards.

• 44:52Speaker 01

  Yeah, exactly.

• 44:53David Hoffman?

  They're not staked.

• 44:54Speaker 01

  Yeah, yeah, that's a good point. Yeah. Yeah. Whereas if you use a liquid token, like

• 44:58David Hoffman?

  It's immediate, right?

• 44:59Speaker 01

  Well, it's not immediate, but because there's so many users, right? Like if all the

• 45:02David Hoffman?

  Right. It's amortized.

• 45:03Speaker 01

  Yeah, exactly. Yeah.

• 45:04David Hoffman?

  Yeah. It's, it's effectively internet with scale, immediate with scale.

• 45:08Speaker 01

  Yeah, yeah.

• 45:09David Hoffman?

  Yeah. Okay. The cool thing about max, max effective balance, like there's also minimum effective balance, minimum effective balance staying at 32. Maximum effective balance is going up to 2048.

• 45:19Speaker 01

  Yeah, I think that's the current spec is, is 2048. Yeah.

• 45:22David Hoffman?

  Yeah, cool. And then last one, inclusion list. This is a big one, uh, inclusion list. Where is this in the mempool?

• 45:27Speaker 01

  Again, this is one where, um, it's just about the trade off of like complexity versus the value. So like, again, it's like if we could have, you know, perfectly working inclusion lists tomorrow and it was like a one line change, obviously we would have done it. I think the the biggest questions here are like, if you do something that's in protocol, can people circumvent it? And what does it like?

• 45:47David Hoffman?

  Can we just define, sorry, what inclusion lists are?

• 45:49Speaker 01

  Yeah, it's like a setback. So inclusion list is specifying a set of transactions that you, as the current proposer, believe should be included either in your current block or like the next block. And and then, you know, the there's many flavors of this, but you could imagine the most extreme flavor is something like somebody else specifies an inclusion list for you, like the previous proposer. And then your block is invalid if it doesn't contain those transactions. So it's like the previous validator is like forcing you to include those transactions. Assuming, you know, their gas gas price is high enough. And so the the the goal with this is just to improve censorship resistance.

• 46:27Speaker 01

  Because you can imagine a validator just like seeing transactions that are censored in the mempool and like wanting to force those in into the network. And so there's like two problems that inclusion lists can address. One is validator censorship. Like, do we want, say that you have, you know, a non censoring validator A, and then the after afterwards, the validator B is censoring. Do we want A to be able to like force B not to censor?

• 46:55Speaker 01

  And and this is probably the part that adds the most complexity, like having like the validity of a block dependent on an inclusion list. But then the other the other use case is a validator forcing an external block builder to include some transactions. So right now, the way MEV boosts works and the whole like PBS infrastructure works is a validator has to choose either to build their block themselves or to delegate 100% of the block's contents to like an external builder.

• 47:27Speaker 01

  And this means that if the builder is censoring, they sort of give up on censorship resistance. They're sort of forced to choose between censorship resistance and like a potentially higher profit. And one thing that that MEF Boost does today to to deal with this is they have like this min bid flag. So if you're a validator, you can say Unless an external builder gives me this much ETH, I'm gonna build my block locally. So you're sort of saying like, I'll be censorship resistant unless there's like a ton of MEV right now, then I don't really care as much. Just give me the most paying block, um, which is still like a valid approach because you know, most of the time there's not huge spikes of MEV. So it's, you can like get censored transactions in them.

• 48:06Speaker 01

  But a version of inclusion list that you could imagine is one where we just force the builder to give you a block that includes your transactions on your inclusion list somewhere in the block. So you're saying, you know, most of the MEVs at the top of the block, like that's fine, you know, build me a super profitable block. But make sure that like the last four transactions of this block are these, or that's somewhere in the block, there's these four transactions. And otherwise I'll just pick my block locally. So I think this is the big challenge with inclusionist is like, do we want a sort of like validator to validator setup where they're each like forcing people to do stuff? Or do we want like a validator to builder setup where it's really about the block I'm gonna propose?

• 48:48Speaker 01

  Um, the validator to builder setup is much simpler to implement. But then the validator to validator setup, um, one, you know, gives us like sort of full censorship resistance at the validator set. And then it also improves on things like base rollups. So a lot of like the pre confirmation, um, in, in base rollups relies on inclusion lists. Um, so again, this is like a trade off between, we could do like this more complex, more powerful version of it. Or maybe just like a small, quick fix now and eventually, you know, expand on it. Um, and this is what people are debating.

• 49:25David Hoffman?

  Just shooting from my hip here, I do really like the idea of very strong censorship resistance that also enables base rollups. I do enjoy that like synergy and serendipity between these two properties. Is this like a, uh, the hard fork after Pectra kind of timeline or is that kind of unknown?

• 49:42Speaker 01

  So the simplest version, you don't even need a hard fork. You could do the simplest version of this, just an MEV boost, right? Where you just say, and then again, it's like, you know, this, you rely on MEV boost for trust here, but like we sort of do already for, uh, for a lot of other stuff. So I'm. I also like full validator set censorship, but I also like shipping things. So if I was like the dictator, I would probably ship the MEV boost change. And then the thing as well, we get out of that is you can you can get like a usage data, right? Like, maybe this is a terrible idea, like there's some flaw in it that we haven't thought about for whatever reason. But like, if it's only a change in MEV boost, it's like, okay, whatever, we can fix it. We can revert it and whatnot, but we didn't like enshrine that in the protocol.

• 50:27Speaker 01

  So yeah, I I'm sort of biased if like, if there's ways we can test things quicker in like a more controlled environment. I'm all for that, but I agree that like long term, having something that's like more robust at the protocol layer is extremely valuable.

• 50:40David Hoffman?

  Sure. Okay, those are all like my big EIPs that I want to talk about that I know are in the men pool. Are there any other like valuable EIPs that we haven't brought up that are worth elevating?

• 50:49Speaker 01

  Yeah, let me check the list real quick. Okay, so we have this thread on Ethereum magicians called frag slash Electra network upgrade meta thread, which I should upgrade the Pectra now that tracks this. So basically, you can find a whole list of everything that's being proposed there. And this is what we're discussing sort of every week on all cordas at this point. But aside from all the stuff we talked about, maybe one one big thing that's also being discussed is EIP 4444 or 44s, which is about stopping to serve historical data from Ethereum as main peer to peer network for all the pre-merge stuff.

• 51:29Speaker 01

  So the idea is like, right now, all the nodes have to serve data about all the way from Genesis. And we'd like to move this to like other data providers. So that when you when you sort of sync an Ethereum node, you can know like for sure what's the latest valid chain. And then you could import your historical data from something else. Like imagine you just torrent it, for example, and then verify that that history actually matches up to the head of the chain. So this is something people have been working on for a while and yeah, want to keep.

• 52:00David Hoffman?

  Is this a snapshot or is this snapshotting Ethereum?

• 52:04Speaker 01

  Um, effectively, like you can think of it as like snapshot in history. And the thing that's that's important is like when you sync the chain and you sync like the current head, you know, you want to make sure that this is secure and so the nodes like do this already. But then when they backfill the his the history, they're always checking that like this history actually ends up at this current head. And so it doesn't really matter if you're confident in like your current head. It doesn't really matter where you get the history from because you can always verify that it's correct. And so right now we're kind of using Ethereum as like a weird sort of torrent seeding network for this. Um, when it's just like not the most efficient thing, like literal torrent networks are more efficient.

• 52:45Speaker 01

  Or you could imagine like going to Internet Archive and just downloading, you know, the first million blocks or, you know, the first 10 million blocks or something. Um, so we're working on just like having a good format for exporting that data, clients importing that data, having a couple of places that like serve this data. Um, so they're just like, again, removes like the burden in terms of bandwidth on the peer-to-peer network. And so that's a big piece of work. Um, EOF, so like a ton of upgrades to the EVM people are still considering. That's a whole other like bucket of of proposals. There's a bunch of proposals around account abstraction and EOA improvements and whatnot. It's another big one.

• 53:24Speaker 01

  Um, and then the other one, uh, the other like bucket I would say is around just like the format of transactions. So how we want to encode stuff, uh, but now we're getting like really in in the weeds. Um, and aside from that, there's a bunch of other like ad hoc EIPs, but I'd say like history expiry, EOF, account abstraction, and then sort of a a long list of of miscellaneous EIPs, um, is what we're thinking through. Um, and if you scroll through that ETH Magicians post, I sort of have a a da- a little diagram showing like all the different EIPs proposed, where they fall, are they like CL, EL, a mix? And we're we're slowly working our way through through that list.

• 54:05David Hoffman?

  Well, Tim, I feel very informed about the horizons of Ethereum and what's beyond them. So, thank you so much for coming on the show and walking us through all these EIPs. Yeah, thanks for having me. This was great. The link that you just mentioned, Tim, I'll get that from you and I will post that into the show notes. And so if you're listening to on the podcast or on the YouTube, you just go to the show notes and find that link. Tim, thank you so much, my man. Yeah, thanks for having me. Bankless Nation, you know the deal. Crypto is risky, DeFi is risky, EIPs and hard forks are also risky. You can lose what you put in, but we are head west. This is a frontier. It's not for everyone, but we are glad you are with us on the Bankless journey. Thanks a lot.