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

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

Welcome to Banklist, where we explore the frontiers of Ethereum. Today on the show, I brought on Tim Baco. It is Hard Fork Day. It's either today or tomorrow, depending on when we release this episode. Dankun is here. The blobs have arrived. We unpack what is beyond the blobs in this episode with Tim Bako, however, because there are other EIPs after EIP 4844 that are going into Dankun. And then there are all some EIPs that did not make it into Dankun that will come in the next Hard Fork, which is Petra. And then after Petra, there are going to be further EIPs. And so Tim Baco 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, 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 Gway, Ethereum Core devs, you know, people who have been and want to explore the bottom depths of the Ethereum rabble hole, this episode is for you. Bankless Nation, we're gonna get to our conversation with Tim and Baco right now. But first, I want to talk about some of these fantastic sponsors that make this show possible. Bankless Nation, I'm here with Tim Baco, the coordinator at the Ethereum Foundation leads the all core dev calls. Tim, how are 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 Dan Coon 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 Dan Coon. And then we'll talk about what didn't make it into Dan Coon, which is which means like what are the EIPs still in the uh all core devs mempool that we know we want eventually included, just didn't make it into this particular hard fork. Sounds good?

Yeah.

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

Yeah. Yeah. That's a good place to start. So

on Ethereum, uh, you know, before the merge, we had both the proof of stake chain and the proof of work chain sort of updating uh independently. And both of those sides had like a different naming scheme of you know to to to name upgrades. So uh on the proof of work side, uh we started, we had you know like Frontier, Homestead, uh Metropolis. And then for a couple of years, we just used variations of uh Istanbul city names, so Byzantium, Constantinople, and Istanbul.

And then we sort of ran out. So we started using DEF CON city names. So then we have the Berlin Hard Fork or Berlin Hard Fork London just following the DEF CON city orders.

And so now we're up to Cancun, just following DEF CON City names. And we had a little actually exception there. We called the Merge Paris as a shout out to ETC, which was a big uh the first big uh community hosted conference. Um so we use those to specify the names for the execution layer upgrades.

On the consensus layer though, they liked using the stars instead. So they use the name of stars and they go alphabetically. So the first one was called Altair, then it was Bellatrix, and then Capella, and now the neb.

But in practice, if you're just like an Ethereum user,

Um, the execution and consensus layer upgrade happens at the same time. Um, there's like different code on both sides. So we need like different names to refer to like the actual changes to the proof of stake side of things, the actual changes to the EVM. Um so we use like Cancun and Deneb to refer to those, you know, sub-changes. But because the upgrade all activates at the same time, uh, we decide to mash those names together. Uh so we have Denkun, which is a mash of the neb and uh Cancun. And then the previous fork, uh Chappella, was a match of Shanghai and uh Capella. So um 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'd probably just use like a city name or a star name. But when they happen together, uh yeah, we we couple the names.

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

Yeah, and in practice, the the fork basically happened 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. Um, but there's no

um 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.

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

Yes, yeah, yeah, correct. So like if you run a validator or you run a node, like you you have to run both, but it's just um and and in in this hard fork you need to upgrade both, but there's no there's no uh 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 layer node, your your execution layer node is fine.

Beautiful. Okay. All right. So that gets the naming out of the way. Uh now because we have the C L and the E L combined, we have earthly cities and uh astral stars uh being portman towed into the same word. And so that's how we came up with Denkun. Uh and then uh Pektra is the next one.

Yes, so Prague and Electra have been merged into Pectra. Yep.

Okay, beautiful. All right. So Denkun is known as the Blob Hard Fork, the hard fork that we get the blobs, EIP4844. Uh, it's the cool one that gives Ethereum its own enshrine data availability layer. We've talked about blobs on Banklist. We've had entire episodes dedicated to blobs. Listen to our episode with uh Domathy about blobs if we if you want to really want to dive into blobs specifically. Um, I don't think we really need to dive into that one because we've covered it so extensively before. But uh Tim, like since we're so close to the hard fork date, like what do you want to elevate about blobs? Uh people are like speculating about like gas fee reductions on layer twos, but I know we don't really know. Is there anything before we move beyond blobs that you want to talk about?

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 denk sharding after. So you can think of this upgrade as like almost the front end to blobs where we we have all the new sort of infrastructure and scaffolding that the network needs to use them. So we have like a new transaction type, which L2s uh can like migrate to to use it.

And then in the future, when we have more scaling uh capabilities with stuff like full denk 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. Um I think that's like a really cool thing where all the L2s have to like do work to support this now, and they've all like done it and are in like the final stages of testing.

Um, 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. Um so I think that's something that's like not not uh discussed enough where

um yeah, we really set like the entire architecture now and we can just keep it expanding in the background.

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

Uh this depending how you approach it, you might need a hard fork, but it's more that the even if there is a hard fork, um

The L2s won't have to do anything. Like so for now they post their they post their data in call data, so they have to switch, you know, the the type of transactions that they make. But

Right.

in the future, when we have more blob space, the the blob transactions of like next week will still be valid and will like integrate with all that automatically.

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

Correct.

Yeah. Okay. All right. Uh so that's blobs. Uh we'll talk actually talk about PyrDas, which didn't make it into Dankun. We'll talk about that towards the end of the show, but this is like one of these like uh uh blob evolutions, blob volutions. Um uh max uh ad max epoch churn limit. That's EIP 7514. That's also coming into Dankun. Uh what should we know about that?

Yes. So right now on the uh beacon chain, when validators come in, uh 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. Um 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. Um

that said

So just to say 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.

correct, yeah, active validators. Yeah, yeah. Um

And and 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. Um

recently,

uh 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 uh

Max amount of validators on the network. And does the even at the current rates of growth, um, is the amount of validators gonna end up being uh too much in terms of like the amount of messages that they gossip uh on the network and and sort of the the requirements uh that that that implies in terms of bandwidth?

Um

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 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 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. Um that's kind of an awkward place to be in. Um so this just gives us a bit more breathing room uh to figure out the right path forward.

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

Uh so it's it 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.

Okay.

Yeah.

Okay, so eight validators per block, eight times thirty-two ETH uh per block is a 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 ESTAke.