EIP-7892: Blob Parameter Only Hardforks

Transcript

As you increase the number of blobs per block, you end up increasing the bandwidth requirements on nodes, the storage requirements, and the CPU requirements. And the more tork, more successful this EIP is [music] because we wouldn't have had the capacity to do it without this. This EIP just allows core developers to adjust Ethereum's blob capacity outside of major network upgrades like standard hardworks. In the future when the scaling technology settles down and things like that and it becomes more like something that we would just give to the community, I think we absolutely could do that.

Hello Ethereum family. Welcome back to Peep Penn any podcast where we peep into Ethereum improvement proposal and bring the people behind [music] them to the mic. This is episode 154 brought to you by EC Institute. I'm your host Puja Ranch and I'm joined by my colleagues from operations and Akash [music] from multimedia team. Today we are diving into EIP 7892 [music] blob parameter only fork. This is a novel mechanism to fine-tune Ethereum's blob capacity without requiring full network upgrade.

This episode is for [music] roller builders, data layer thinkers and anyone closely following Ethereum [music] scaling road map. EIP7892 is anformational EIP documented in February 2025 [music] by co-authors Mark McKay and Rahul Krylani. [music] It is currently in draft status and aims to define how Ethereum can introduce targeted parameter only for we would walk through the proposal and I'm really thrilled [music] to welcome one of the co-author of the proposal ET dreamer also known as Mark McKay. [music] Welcome back Mark and thanks for joining us again.

>> Yeah, thanks for having me. Excited to be here. For our new subscribers, Mark is a client developer at Lighthouse and has given a fantastic talk on client preparation during the merge, which was one of the most exciting upgrade of uh Ethereum at that time. If you haven't watched, be sure to check out our episode 81 on Penney. Mark, it's been a while since we had you, so it would make a lot of sense to maybe learn a little bit more about you. The Ethereum world has changed a lot since then. If you could briefly share a bit about your professional journey since the merge and what have you been working on, what's currently excites you, interest you most

outside of this proposal? >> Sure. Yeah. Well, I've been a a lighthouse dev since 2021 and basically right when I got in, I started working on the merge. So, that was really I mean that was super exciting and fun when I was especially when I was new. It was really cuz the merge was basically like the biggest upgrade that we had pretty much telegraphed since the beginning of Ethereum. I mean the idea of going into proof of stake was in the the yellow paper I believe. So yeah it was an exciting time to join and since then I've you know stayed working on Lighthouse and at Sigma Prime and more recently I feel like I've been sort of involved in looking at the larger picture. I'm

trying to be as best I can a bridge between the client devs and the researchers because I feel like the researchers in Ethereum have a good picture of like kind of what our long-term goals are and where the protocol is headed in the long term while client developers have an inherently short-term view of the protocol because they're like working on the upgrades that are right in front of us right now. And I am a client developer, so I do work on those upgrades as well. But it seems that where these two groups mostly meet is when deciding what upgrades are going in the next fork. And often times like devs are sort of heads down

delivering code for the current upgrade and don't have enough time to be as much across like what we would do in the medium term and what the trade-offs are and things like that. And so, um, at least in the last year or so, a lot of what I've been doing is trying to answer those kind of questions is like and have a good understanding of what the or where we should head as a protocol in the medium term and what I think we should do and that especially with this most recent decision on Glam Amsterdam, I've been pretty heavily involved. It's a tricky one. Like I would say in the history of the beacon chain there's been six upgrades or so and all of them with the exception of Electra so far like

it's obvious what our kind of main priority is but Glam Amsterdam is another one of those ones where like there's competing priorities and so it's difficult for us to determine what should take precedent and so that yeah that's kind of what I've been working on recently. >> That is pretty interesting. Of course we can understand like why this proposal to think of intermittent folk which is not like full proposal heavy. So yeah we are all looking forward to learn more about this EIP. So without further ado let's peep in.

>> Sure. >> Yeah. So just to give the the basic background in the EIP first and what the motivations are we'll just start with the simplest question is what are blobs? Those are just places where that they're the side car that's attached to blocks or that is propagated along with blocks and stores where all the L2 transactions. And so blobs are all about L2s. It's where L2s store their transactions. And so more blobs equals more L2 transactions. And all the L2s want us to ship as many blobs as we can. So why don't we just increase the number of blobs as much as you know is needed?

Well, as you increase the number of blobs per block, you end up increasing the bandwidth requirements on nodes, the storage requirements, and the CPU requirements. And while we could always do that, you know, if you push hardware requirements too far, you end up risking centralization as people don't want to run full nodes. So, we can't push that indefinitely far. And so, how can we increase Ethereum's blob capacity without increasing hardware requirements? generally new scaling technologies. So we've got pure das that's coming around in the next hard fork in Fusaka and then in a future one there'll be full dank sharding which adds a whole another dimension and should further increase capacity and

then there's other ways that are kind of outside of normal major network upgrades like mostly around networking improvements things like RLNC for like gossip improvements we can tune certain parameters around gossip we had implemented a new kind of gossip message called I don't want to kind of limit the an attempt to limit the wasted um improvements and I'm sorry wasted um bandwidth of propagating messages that had already been received and then there's um things like distributed blob building but these are all things that basically occur they don't necessarily require major upgrades and major coordination they can just happen

outside and in parallel to major upgrades and So now we get into what does this EIP do? What is what is a blob parameter only hard fork and what are we trying to achieve? In one sentence, this EIP just allows core developers to adjust Ethereum's blob capacity outside of major network upgrades like standard hard forks. So we don't have to like normally if we have to have a hard fork, there's a whole bunch of code change requirements. In fact, like every hard fork on the CL side comes with thousands of lines of boilerplate code. And so this idea here is like we don't we can just change these parameters, but we don't need thousands of lines of new

code. We can just change a little config and then you know ship a new version of the client. And this is just much much more efficient for core developer time which allows us to like do this outside of major upgrades. So we don't have to piggy back on major upgrades. know, you know, why would we want to do this outside of major upgrades? Well, there's three primary reasons. One, it allows us to ship those upgrades faster. And I I'll get into each why. Uh I'll justify each of these as we go, but we can ship upgrades faster. Uh we can do this with enhanced network stability. And it better allows us to have the limit, the blob limit that we set by the

network actually correspond to the true limits on the network. We we can adjust the limit so that it is truly reflective of Ethereum's actual capacity. Okay, so how does this allow us to ship faster? Well, major hard forks that are named hard forks like um Capella, you know, enabling withdrawals and then um 4844 that's what created blobs. We have, you know, Electra and we have Faka coming. But these kind of major upgrades so far have come roughly once a year. We do have plans to make them more frequent, but even with them being more frequent, they're only about twice a year. So, they're kind of infrequent. And if they're infrequent, that means that we have to be really careful about how we

increase capacity. Like if we can't change this in a more flexible way, then we have to be careful about getting the the capacity right exactly at the time of the upgrade. And this can be difficult for a number of reasons. The reason it's difficult to get this right is that there's competing forces. If you pick too conservative of a of a target for the blob capacity, you end up wasting scaling capacity. You leave that on the table even though the network could handle more. If you pick too aggressive a target, um it could be that the network can't actually handle that many blobs yet and then you risk network stability, which is something you definitely don't want. And so, you know, it it puts a lot of extra pressure if we can only do this during major upgrades.

So like how do we actually end up measuring Ethereum's blob capacity basically rely on pandops lots of different test nets that we have public test nets we have well shadow fork mainet we have attack nets like actual test nets designed that we try to stress test the network as much as possible to try to find what these limits are. You know the limits are are set by kind of physical parameters. How fast can you you know transmit objects? How fast can you verify proofs? All sorts of things.

And all of these kind of come together and and you you sort of find bottlenecks as you do this kind of testing. But it's important to note that like no test net can perfectly reflect mainet. Nothing beats mainet data. Like mainet will have a particular client distribution which will affect these results. Nodes will be geographically distributed in certain ways. Especially with um Fusaka and with Pieras, we introduce a new kind of node um that's called a super node which has all the blobs for all subnets and the distribution of super nodes would affect the network capacity and even the stake distribution would affect the network capacity. In Fusaka with Purdas, if you have more validators on your node,

you're required to store more blobs. Um, and so that, you know, decreases the amount of time. If there's more stake distributed in more areas, it it it means the blobs are better distributed in more areas, which will allow them to propagate faster. So like basically like mainet is going to its own specific network and we can't really replicate it exactly, but we can try. So it's it's always a game of like approximating what our true limit will be. But with blob parameter only forks, we unlock a new strategy. So instead of having to get the capacity limits exactly correct, right, when there's a new upgrade. So for example, when we had 4844 and we

introduced blobs, we set a target of three and a limit of six. And then you'll notice that in Electra, we upgraded to six and 9. To my knowledge, I don't think that any particularly changed. I mean, I know clients did get a bit more efficient, but really we just realized that we could handle six and nine and so a hard fork is a perfect time where we would like coincide it with Electra, but we were, you know, in theory we could have shipped that much sooner if we had already had block parameter on the hard forks and the capacity every time we ship a new scaling solution, whether it be pure or full dank sharding or 444 or whatever, the numbers change and but the

problem stays the like which is just that you have to pick a target that is still stable but not overly aggressive but not leaving a bunch of capacity on the table. So with the ability to upgrade outside of forks, we have a new strategy where we could basically just ship the major upgrade when it's ready. So this is actually already entered into discussions on how we ship pure. So we can just like pick a more conservative target and just ship pure to begin with cuz we know we can upgrade later. And then once we ship pure we can get more numbers on things like the stake distribution, the super node distribution and and actual propagation time measurements and things like that about mainet and then we can use those

to inform our test nets and get better ideas of the true capacity of the network with Fusaka fully shipped. Once we've, you know, gathered this additional data and we can test with higher limits and we can ensure that they're safe, we can just adjust upwards as we feel. So this allows us to not only ship Fusaka faster, but ship with a more conservative target at first so that the network is like more stable than it would be without this and then slowly increase while maintaining stability. So ship faster, enhanced stability, and then we just end up having better accuracy in terms of the the network's actual capacity for blobs.

So like I said, there are these kinds of other enhancements that could occur outside of hard forks. And instead of waiting for full I should say outside of major network upgrades not hard forks since these are hard forks but since these occur outside of major network upgrades we don't have to wait for them if the network is ready for a capacity increase we can just increase the capacity. Um yeah so basically that and now just to get a little bit of the technical details of the EIP. So how do we limit the number of blobs in the network? We just I mean this has been since 4844 we have like a 1559 style pricing mechanism in which the blob count is very

analogous to the gas limit while in gas used. So there's one parameter of max blobs per block. Very simple. You can't have more blobs than this parameter. There's a target blob for per block, which is similar in EIP 1559 with the gas limit. It's just half whatever the gas limit is, but we can we don't necessarily limit it to just being half when it comes to blobs. And then there's this base fee update fraction, which really just controls how sensitive the blob pricing is to changes in the number of blobs since the last block. But yeah, you can think of it as as max target and then there's like a sensitivity of the price basically these three parameters.

And so the idea is to make these three parameters upgradeable outside of regular network upgrades. It's fairly simple. The EIP all it does is specify like the configuration format. So there's a configuration on the consensus layer. there on the consensus layer, we don't actually have a a parameter for targets or the base P update faction. All we have is a maximum. Um, so that's the only thing we need to adjust. And so it's it's fairly simple. We just have a blob schedule object allowing us to specify at what epochs the parameter changes and what the value is. Um on the EL they have a similar thing where they specify rather than epochs timestamps

and there is a one to one correlation between block time stamp and epoch. So they just have to make sure that those correspond but they're just specifying the target max and base fee at a particular block time stamp. And so that's really all the EIP specifies. It's fairly straightforward. It was not too difficult to implement. In fact, the difficulty came from basically some networking stuff. This is what the co-author R helped a lot with. It was basically we wanted to ensure that nodes that did not upgrade in time would quickly be kicked off the network.

And that required us to have changes in things like a fork digest, which is what we do at standard harded forks because we didn't want any node that doesn't upgrade is going to be on a new chain. And we didn't want traffic from that chain like clogging up mainet and basically slowing down mainet nodes. And so we just had to ensure that that with new upgrades came came that. It's important to note that the BO forks are still hard forks and so it will still require clients to make releases but it's fairly easy for us to do. So all we have to do is put in a config upgrade and and put in a a change the config and cut a new release. So that saves a lot of deb resources but also client like nodes will have to upgrade before this

fork if they want to remain on Ethereum. So this will require all the standard infrastructure that we have for communicating hard forks where we announce it on blog posts. We give a lot of warnings. We reach out to the um ecosystem to ensure they like major ecosystem um participants like staking pools and stuff make sure they're all upgraded. But other than that it it's fairly straightforward. Um, and that's I mean the EIP is fairly simple. That's pretty much all there is to it in terms of what I had for a presentation. But yeah, happy to happy to take any questions about this.

>> Thank you so much for this presentation. This is anformational AIP and it is very well captured. It seems like it will be similar to EIP7840 which was um in spectra upgrade. It was like add blob schedule to EL config files. The proposal may not be deployed on the mainet may not be a part of traditional network upgrade because that's not a core proposal but instead this is helping us to define how smaller upgrades can be brought to the mainet. So thank you again for sharing it. >> Yeah >> I do have a few followup questions in the presentation you mentioned that the upgrade will happen when the network is ready for the capacity increase. what it actually means like um what are the coordination or signals that could

trigger a BPO hard fork. >> So I believe when I was saying that I was more talking about regular upgrades or regular network upgrades. So what I mean by that is if we didn't have this EIP, we would have to implement a whole new scaling strategy like pure DAS and then we would have to do a significant amount of testing and measurements to try to get the limit that we set as close to the actual capacity as possible and we'd have to do that kind of blind cuz we wouldn't have mainet data. With this CIP, what we can do is we can implement pure DAS, but then we don't have to ship it with like a really highly tuned parameter for the blob limits. We can

pick something much more conservative like we'll we'll still obviously test it, know that it seems safe and everything, but we can be sort of overly conservative there without and and not have to risk network stability. So what I meant by when it's ready, I mean when the pure is ready or the scaling is ready. Now there's a kind of separate question there which is like well how do you work with a a BO fork? How do you determine that? So to answer that question, it's like I would think that generally what our strategy is going to be is and and we are still working it out by the way like the schedule is not set in stone yet for what um it's going to be under pure DAS. Um but generally

it's going to be that we have some target that we think looks quite safe. We're we're going to determine that through all of our test nets and things like that. We're going to have to have we're going to have to see how they perform under poor network conditions. We're going to have to see how they perform with different distributions that we think are accurate, things like that. And basically like we'll pick a number that the network seems stable even under sometimes poor network conditions that could happen on mainet.

And then we'll ship the fork with that. We'll ship like Fusaka with that that number that we pick. And then once it's live on mainet, we can do more things like measure propagation speeds, try to get some estimate of stake distribution, things like that. And we can see how this is performing on like real mainet conditions. And at that point, we can do more test nets and more simulations that look more like mainet while we increase these numbers and we can see what looks to be a safe number there and then just increase it later. This is the strategy that I actually would prefer. You know, it's a close coordination with Panda Ops team and I mean it's one that's kind of

up in the air. Other people argue for even additional strategies things like you know what if we actually define the hard forks to be cuz we can in advance determine by how much they increase and when. So we could have like a regular cadence. We could go some amount at launch and fork and like a month later, you know, some higher amount and a month later, some higher amount and just leave it like that and then measure mainet and see how it goes. And then at some point if we're like, yeah, I don't think we should increase any further. Then we'd put out a new release that cancels maybe a future upgrade. There's it's actually a fairly open space. So yeah, and and it's still kind of under debate.

>> You mentioned that the adjustment is going to be upward. So, do you think it is only going to be unidirectional or or could there be a situation in which it can be reconsidered to bring it down? >> That's a great question. The CIP enables both directions and we do actually test both directions, but we would only adjust downward if we had actually gotten it wrong and like the network wasn't stable under the under whatever parameters that we had decided and that we needed to adjust to a less aggressive target. And we could do that. I think we would in principle want to avoid that scenario uh because we don't like network instability, but the upgrade does enable us to do that. And that's

actually an important thing to test and be aware of as an extra like just in case we do get it wrong, we can go back down and we do and like you said, we do test that. >> It's good to know there there is flexibility already provided with this proposal. Well, I understand during the time of Petra upgrade there were different limits we discussed like 2 4 3 6 and 9 like that. Similarly, when we found this proposal the BO uh before draft like pre- discussion we can say that it was considered only two fields to be changing but now the proposal consist of three fields to be changing.

My question to you is like are there other blob related variables which are intentionally excluded or do you think that these are sufficient and others are not that important to be considered? >> Right. Well, there are other variables that we could change on the CL side, for example. There's a lot of variables around how many subnetss we have and things like that that in principle could change. And in fact, they did discuss on the EL side potentially making the maximum number of blobs per single transaction configurable in this same schedule, but they decided against it.

Basically, there's like competing forces here. The fewer parameters that you make changeable, the easier it is to like code this and do this. The more parameters you add, the more difficult it is to write that because you've made all of those things now a function of epoch and you have to like make sure that in all the code pass where you use them that the epoch is accessible. So I mean those would be the two forces that are involved. I would say we picked the three of them because those three for one were already included in the earlier EIP you mentioned in the blob schedule and so like they're naturally already changed in the config in the same place and so like it doesn't really require extra coding to include all three but

also like they're grouped together because like increasing you know we could have a BO fork that doesn't change the max and just changes the target and at that point we might want to change like the base fee update per action like these parameters in some sense are kind of coupled like they you sort of once you change one it would inform how you would change the other and so it makes sense to at le to include this sort of minimum set but you could include more parameters in fact you could in theory include parameters that aren't even related to blobs that was one of the proposals that kind of came out of the discussion which is like you know we could have parameters that yeah they they're just not even related to blobs

and it's come up even in discuss of future forks of things that we might want to change outside of hard forks. The trouble with this is that like I said, it's the more things you try to change, the more you have to kind of clutter the code with extra code to handle changing these things outside of hard forks. And then so it it can make the code more difficult to manage. And then also just like when we agreed on this EIP, we limited the scope to just blobfacing things. And if we were to have like maybe like a general parameter hard fork EIP that would need to be like discussed and agreed upon on its own on ACD before and so like the scope was limited to just this.

>> So it seems like u this is going to hit both layers like there would be some changes required on consensus as well as execution layer. I'm curious to understand for client specs, are there naming or versioning standards in place for identifying BPO forks in codebase? I'm not sure if this can be comparable to fork identifier that we used to have it before. >> So well with naming that's more kind of like a regular hard fork and I think the E did at one point flirt with the idea of giving them names. Anyway, I know that hard forks on the E side are actually significantly easier to code than on the CL side. And you know what? This is kind of a subtlety, but if we didn't need to

kick off nodes that hadn't upgraded, then we could in principle put this entire thing just on the E side and we could name them make them named hard forks because that's not that difficult for the E. But since we need to kick them off, we need to change like the fork digest and stuff, it it ends up having to be on both sides. And then I kind of so I think the question was about standards like well we do we do have a standard defined in the EIP and that had been debated a little bit. It it changed throughout but I think we've kind of settled onto something stable. I don't think that the CL has any plans of giving them names. I and I believe the EL sort of gave that up too, although they might just call it BPO1 and two, but I think they could give it a name.

And there is kind of something in the Yeah, they do have like a a little time defined in the schedule where they could name it something beyond BPO 1 and two. So in theory, you could give them names. >> And I found a very interesting conversation about naming the BO folk like we had E folks named on city, CL folks name on stars. So there was this conversation of having it named after Nebula. That was pretty interesting conversation. So maybe we can go there. >> That's a good idea. I I didn't even see that but I wouldn't be against it.

>> Very well. You mentioned that for BPF folks perhaps we will collect data which are on the main net and pass it on to the test net to figure out like when is the right time. Do you think uh with this practice in place still whenever we decide to have BPO fork it should go for the test net before the mainet roll out? >> Yeah, I mean it likely will. I don't know that the public test nets on Ethereum are as important as the kind of shadow fork and and um I guess the word I used was attack net. I think those are probably more important in terms of really finding what the limits are, but I do think just because every upgrade

goes through the test nets first that these likely will as well. Although they, you know, in theory they could go on a more aggressive schedule than regular hard forks. I suppose putting any upgrade on test net is not only for testing purposes but it also gives a lead time for the community to prepare that this is something that is coming up because we open this announcement of public test net like upgrade on public test net any infrared tooling can also go ahead and test that. However, attacknet does serve the purpose even in a better way but still it's good to have it there.

>> Yeah, for sure. And then there might be contracts that in some strange way are dependent on these. So you and that are deployed on test nets and so you you might want to run them through. >> That's right. Yep. Well, I understand some of the discussion will be on all core devet. But if we need to understand what is or who is going to initiate and approve this BO4 in practice, would that be just ACD group like all client team coming over there or are we planning to have a working group or maybe another forum to initiate this uh discussion of having BO folk?

>> That's a good idea. I think it's a good question. So I do think that to some extent the question is a might be a bit separate from core debs in the sense that yeah you might assign some subset to like go look at the question and that's generally kind of what we rely on um panda ops for those kinds of things and then core devs often make their decisions based on what they hear from panda ops. So like it's likely that it will be decided on ACD but it would be perhaps like most of the work that goes into informing that decision would be um a subset of core devs or or a subset of panda ops.

So but I don't see any way that the decision would be outside of ACD the final decision. >> Yes, of course. I mean that makes a lot of sense and that is kind of canonical source of truth for the community like whatever is upcoming. >> Yeah, >> I understand you mentioned that these folks could be infrequent. We do not have any cadence in mind but just as you can see the development of network is there any estimate like how frequently we can see it? Can we see it like once a quarter or maybe once or twice same as the network upgrade we have?

>> Yeah, I would expect that the I mean in principle we could it's a funny question because we sort of have some of these targets for gas limits right now um because we're scaling L1. So in principle like we could have like a more aggressive targets in terms of how do we increase capacity of blobs at the same time and trying to hit certain schedules. I don't think there's anything in place right now. I think right now it's more likely that we would just try to match it closely and then it would basically like we'll we'll try to get as high as the network has true capacity for and then if we ever have a feeling that there's

more capacity that's left on the table that you know we'll investigate that and and see if we can increase the the limit. major changes in capacity generally come from these major scaling changes like pure and like full dank sharding though but like I said there's these more minor ones too so basically long story short I suspect that we'll try to get as close to the actual capacity as we can but that's a moving target and so we'll try to change and I don't know that the actual capacity will change with regular cadence rather than maybe like I wouldn't say random but not regular Yeah, we may not have a fixed cadence for that but we can expect frequent upgrades there.

>> Yeah, >> very well. As I understand, uh this upgrade may not require a lot of coordination from client teams like clients point of view but it may require some kind of coordination from community point of view especially with respect to infrastructure and tool providers. So how should like wallet explorer and layer 2 tooling providers track and prepare themsel for uh upcoming BPO folk? >> So I don't know that this has really many implications for wallets or even the other players that you mentioned like block explorers outside of like making sure that their nodes are upgraded on time. In terms of layer twos, it's funny because layer 2s like they already have their own internal

capacity limits it seems. And so like they'll know that an upgrade is coming, but even when an upgrade goes live on mainet, they don't necessarily like immediately start using that capacity. That's what we had seen with Electra. So because they have their own bottlenecks in their infrastructure. So it's like we'll provide the extra capacity on L1 and then the L2s themselves will do their own inter internal research to determine that they can safely use this extra capacity with more transactions and things like that. So it's already kind of involved on the L2 side even isolated from mainet. So I imagine from us it will just come with like okay by this time you'll have more capacity and

so you start testing. >> That is interesting. I wonder if uh there is any plan of having a dashboard or something like that in place for community to regularly follow. I suppose that could be helpful >> some already like doing analytics dashboards but yeah it would be interesting to check. I would say that like this the more forks we have I guess if you want like a way of measuring the success of this it would be like the more forks we have the more successful the CIP is because we wouldn't have had the capacity to do it without this. So, and every fork is presumably necessary.

So, >> well, you pre-answered one of my questions like how would you ensure the success of this uh proposal? >> Yeah, good job there. Well, as we understand that the layer 2 projects would be more benefited with these frequent upgrades. I wonder uh will rollup fees or performance shift as block blob capacity increase will it be affected in any way? I would imagine that they're they should go down because they just have more capacity. Well, I guess that can often times get eaten up by invots, too. So, they'll have more transactions per second, but if that gets eaten up entirely by bots that are arbitrageing everything as fast as they can, then maybe that doesn't affect fees

too much. Now, if genuine usage comes, then those bots have to pay more and that changes things. So, but in general, more blob space is more transaction space, which is lower fees. That's good to know. And just u being on the same question, what level of predictability can layer to expect when Ethereum provides this information of uh data availability to them? >> I mean, so they'll know that we'll be pushing as much as we can. I like I said, I don't I don't know that we'll necessarily pick super regular schedules, although that I mean that is one of the proposed strategies, but it's just that it's still being debated. So, I guess keep your eye on ACD soon because I feel like

we'll be finalizing the schedule more and once the schedule is more and more solidified, then you'll know exactly what the the roll out will look like. Um they'll definitely see a capacity increase coming soon with Faka though >> right I was going through the proposal and it suggests that there is no security consideration found I'm just trying to understand here that how does these uh BO folks make sure that they don't break compatibility with any other ongoing upgrade or EIP if they are work in progress.

>> It's a good question. I think the answer is kind of a funny one. It's something like once an EIP is in the code, it's really on the future EIPs to not break compatibility with it sometimes. Now, this can get tricky when you talk about the interaction between various upgrades. Certainly with things like Glamsterdam today, you know, we have we're looking at DPBS and we're looking at Fossil and stuff and we're looking at delayed execution and shorter slots and we have been debating how these all interact with each other and so that does get important with this EIP. I guess it's just that it changes so little. Um, it is kind of funny because if we had not had it be cross layer and we hadn't required that the network kick

off nodes that haven't upgraded and we just chose one layer, then this would would potentially have some issues with EPBS. Not terrible issues. We would just need to amend the CIP to have the upgrade be on both layers. But yeah, I had realized that while making this presentation that it's actually good that we have a two-layer upgrade. I would say that generally like we just try to surface these issues as soon as we can try to think about how these things will work but it's it can be like a tricky problem to solve like the more general question of like how do you understand the impact that potential upgrades have on other potential upgrades that can be a very tricky question and it can be tricky to get enough people in the same room who understand all of them to discuss that

and hash it out. It's one of the things that goes into the process of deciding what EIPs get in here and this EIP specifically. I would just say that like it's simple enough of a change that we don't really anticipate any compatibility issues. >> Well, the proposal is currently in the draft status. I am hoping if discussion continues perhaps we could identify ways to keep a check balance. So it should not like the proposals or adjustments made with BO does not affect any other EIP which is coming up with different upgrades.

>> Yeah, I I would think that at this point this EIP is pretty, you know, that when they first get proposed, they then change a lot. They kind of settle. This EIP is pretty settled. I mean, I just don't know. I can't even think of how it would upgrade any how it would touch or affect anything else that we're considering. It certainly hasn't come up in any of the um discussions that we've had. So >> yeah, I mean it was just a hypothetical question even I'm not sure if it is going to affect well well as you mentioned that is that this proposal is pretty much uh spec ready. Perhaps this is the right time we can move the proposal to the review status. So yeah consider making up a request to update

the status and move it to the review status for the proposal. True. The only thing I might change is the uh the the EIP renders with these commas with red which because it's not considering it valid JSON right now. So I might put brackets around just to make it valid JSON so it renders nicely. >> Yeah. All right. Just looking ahead um when we uh continue to do these BPO folks frequently. Could you imagine a situation where these blob parameters update eventually be automated or maybe by community voting? What do you think of that?

>> Yeah, that was one of the things that came up which was I mean today the gas limit is done via an onchain vote and so you know we could in principle do the same thing with an onchain vote here. The only reason we didn't do that yet is like we are changing the capacity rapidly right now. you know, things like pure dash and then in the future full den sharding. And so it doesn't make a lot of sense to leave that up to the community at this point simply because like the answer to this question even the core devs don't have a good grasp on right now. Like the only the best answer we'll have is through thorough testing.

We're going to be the only ones who are going to do that. And but even if we did leave it up to the community, as we can see through the way that gas limit discussions have gone, the community generally waits for the core devs to signal that a certain limit is safe and then they upgrade their nodes to reflect that gas limit. And so it kind of sell either way the decision sort of tends to remain with the core devs as it is. And so making it a config change was just like the fastest, simplest code change we could make right now so that we can deliver fast. But in the future when you know the scaling technology settles down and things like that and it becomes more like something that we would just give to the community I think we we absolutely could do that. Yeah, it was

just really about speed of delivery and the fact that it didn't make a lot of sense at this point in Ethereum's road map. >> That is totally understandable. This is at very nent stage. We haven't started it. Maybe after 8 to 10 BPU folks if it feels like that community can own and they have a better visibility of what and when to be done it's a good idea that client devs are open to the idea of handing it over. >> Yeah. >> Very well that concludes all my question with respect to this proposal but I do have few other questions for you and before I get into that rapid fire round set of questions I wonder if you would like to share any message to the community. We understand Ethereum's 10th

anniversary is coming soon. So, if you have any message for the community, >> I mean, here's to 10 more years, I would say. I'm very excited in the direction we've headed. I think we've done pretty well with the challenges we've faced so far, and I think we're going to keep making Ethereum the best network that we can can make right now and happy to have a community like we do in Ethereum that cares so much. >> Thank you so much. Um, and your words are true. Ethereum community is great. I have never seen any other community like this. This is one of the most empathetic community I can say. They are ready to support with everything possible.

>> Yeah, there's a lot of care. >> Very well. Uh that brings us to the last section of uh this podcast which is called as rapid fire round. [music] So [music] in this round we try to come up with the response in one word, one phrase or simple response that [music] comes to your mind. The first thought that comes to your mind. >> Okay. >> Ready for that? All right. Rollups in one word. >> Failing. >> Most underrated EIP. You cannot name your EIP.

>> I would say 7732. Like the enshrined proposer builder separation. It's just a very subtle EIP and it takes quite a lot of like wrapping your head around to see why it's great and so it's it flew under the radar, >> right? And we are seeing a lot of comments on that right now. I believe community is trying to collect more information in order to consider that proposal for Glamsterdam. >> Yeah, it's basically the definition of underrated because not see why it was so good for a long time.

>> Very well. My next question is a non-Ethereum protocol you admire. >> Okay. I mean, Celestia is cool for the the technical aspects of what it tries to do. And I mean, I got to give it to Bitcoin for just being the first chain with so many concepts introduced at once. So, those two. >> Cool. If you have to respond, blob or dankshing, which is most exciting for you? >> Um, dang sharding probably. I mean, I guess that's a question of pure versus bang dang sharding since they're they're both sharding blobs, but I like dang full dang sharding.

>> Yeah, you are right there. Very well. Uh my next question is one myth about protocol death that you would like to burst. Yeah, I mean there are I will say that it's the most talented group of people that I've ever worked with. And the nice beyond that what's also very great is almost all of them are very humble and that's like really nice in terms of like someone can come in who's not really been a part of the community and share a good idea and if it's a good idea it can get a lot of traction very quickly and I have never seen a place like that. Like that combination of talent and humility leads to a lot of great discussions and a lot

of openness and good design. >> Right. Many people think that client def makes all the decision or maybe if they can influence a client they can get their proposal passed. >> Yeah. I mean I think you will need to get people in your court. You will need to get champions in order to get enough attention. That's true. I don't see a way around that. I don't know how it could poss like I don't know how any other kind of governing structure could work, but in practice, if you have a good idea, a lot of the times, you know, you can get it out there.

Um, and we're making more attempts in recent times to involve the community more. So, I mean, I feel like a lot of times people even if they have ideas, some of times they end up becoming cordovs because like anyone >> That's very true. >> Anyone can become a cordov. >> Very well. Just imagine you have been given an opportunity to swap your role with another client team or any other client dev. Would you like to name someone or some client just for a week? >> Sure. I'd love to go see what the EF does on a day-to-day basis. Every time I go over there like I mean and both offices I could either go into Colorado one or the one in Berlin. I've been to both. It's just nice because they have

like a lot of them in the same room and we're so distributed that the only times that we get to talk to each other in the same room where like a lot of progress is often made is is on these retreats like the one we had a little bit ago the inter where like I feel like we advance the discussion on what should happen in Glamsterdam by like a year in two days by just having enough people in the same room. >> Yeah, that makes a lot of sense. I understand there are a lot of challenges with client devs working in decentralized fashion. Having them in one room may help make decision faster.

>> Yeah, it's like you said when you ask like well how do we make sure that EIPs don't interact with other EIPs in ways that we don't want? It's like the only way sometimes like you you either have to personally be across both EIPs and understand exactly how they're implemented or you know have both people in the room to try to think about it. So I mean and you can obviously reach out to them you know remotely and have them think about it as well but it's just that yeah when you have enough people in the same room really looking at a problem especially when it has multiple facets and multiple dimensions like you you really can't beat that and that's why like I would if I was going to trade places for a bit I would just go somewhere where there's like more core

apps I would just go to somewhere in in Berlin or something. >> Very cool. I understand this is a community- based project or process. So, uh what is your favorite go-to place? Is it GitHub? Is it Fellowship of Ethereum magician forum? Telegram or Twitter? >> Yeah, I would say I get most of my messages on Telegram in terms of the wider discussion that happens on X a lot of the times and Farcaster. Yeah, I mean I think I get a lot of like one-on-one communication through Telegram and through like Discord. >> Well, my next question is about EIP. Um I know this proposal is working towards changing the process of network upgrade.

If you have an opportunity to change one thing about how EIPs are handled today, what it would be? So I think what's needed is that each client team should have like maybe a better process of having people either across the proposed upgrades like either having you know splitting this work up between multiple people or having one person that's really like spending a lot of times thinking about that medium-term what goes in the next fork so that they can be like a a point of contact on that team that you talk to about different things that are across different things because at the end of the day we all kind of come together um on ACDC to decide these things and to get a

better decision, we need more people across it. And it comes at a cost of like, well, I I was going to work on this thing we need for the test net, but I spent all day like looking at this potential upgrade and understanding the nuances there, you know? So, it does come at a cost, but it's important like making the right decision is important. It ends up saving more time. So just to summarize like have a more concrete role on each team on who is looking at potential future upgrades. >> Thank you. You very well answered all of the questions. Once again the entire conversation was incredibly insightful.

Thank you so much Mark for walking us through the motivation mechanics trade-offs [music] behind this proposal. Lovely talking to you. >> Yeah thank you. Pleasure talking to you. Dear listeners, if you want to learn more about this proposal, please check out the [music] full proposal and community discussion. Links are available in show notes. If you enjoyed this episode, don't forget to like, share, and subscribe to the channel for more deep dives into Ethereum's evolving protocol. [music] Your support helps us bring Ethereum governance and education to the community. See [music] you in the next Penip.

Thank you.