Loading summary
Transcript96 lines
- [00:01]
A
Hi everyone. Laura here. I'm actually on vacation this week, so we have a special guest host stepping in, Christine Kim. Christine has been covering Ethereum's roadmap for years and she sat down with core developer Preston Van Loon to dig into the upcoming Fusaka upgrade, what's inside it, what it means for users, and how it affects layer twos and client teams. It's a great conversation and I'm excited for you all to hear it. Enjoy. Are you a builder who needs to add on chain trading to your product? The Uniswap Trading API from Uniswap Labs offers plug and play access to some of the deepest liquidity in crypto. It's on chain execution at an enterprise level. More liquidity, less complexity. Visit hub.uniswap.org to learn more. Mantle is launching the Global Hackathon 2025 to accelerate the future of real world assets. With a $150,000 prize pool, backing from a $4 billion treasury, and direct access to Bybit's 7 million plus users, this is the ultimate ecosystem for builders.
- [01:07]
B
Historically, we've moved quite slow.
- [01:11]
By design, right? Like, there's just a lot of moving parts here. And the fact that we can get two in one year is really impressive because it means like, people are finding a rhythm and like getting through. And what I'm hearing from my peers, other core devs are not hearing excessive burnout. Like, this isn't like, oh, we just worked twice as hard because we were already, you know, working 110%.
- [01:33]
C
Hey everyone. Welcome to this special episode of Unchained. I'm Christine D. Kim, the host of the Ready for Merge podcast and the writer of the ACD After Hours and BTC Before Light newsletters. I'm very excited to host this episode of Unchained because we're going to be talking about the Fusaka episode upgrade, which is coming up very, very soon. And I'm joined by a very good friend of mine, Preston Van Loon, the founder of Prismatic Labs and a full time client developer for the Ethereum consensus layer client Prism.
- [02:06]
B
So.
- [02:07]
C
Hi Preston.
- [02:08]
B
Hey. Happy to be here with you. Yay.
- [02:11]
C
I'm glad that we're doing this episode together because as I was just mentioning before we started this recording, when I was ideating the show or this episode with the Unchained team, we knew we wanted to talk about Fusaka and also give it a little bit more of a focus on how Fusaka is going to impact L2s. And uniquely the Prism client is maintained by Off Chain Labs which builds Arbitrum and L2. So I feel like, yeah, you have a really like you're in a position where you're building the L1 but have very close access to a major L2 that you're building.
- [02:54]
B
Yeah, I would say that Arbitrum or off chain Labs is our biggest customer. So we care deeply about what's happening in L2s and how we're improving and impacting them. So there's a lot to talk about here in Fusaka. This is a really exciting upgrade.
- [03:10]
C
Yeah, I want to talk about the specific impact of Fusaka on L2s, but very generally let's talk about the kind of like biggest eips or biggest impacts coming up from the upgrade. So Fusaka, as we were talking before, the Koroni has about 12 EIPs in it. Can you give an overview of the main features, the biggest impact of this upgrade on various Ethereum stakeholders? Give us the bird's eye view of this major upgrade?
- [03:45]
B
Yeah, I think that almost all these are very exciting. There's some that are like more, I don't know, maintenance level EIPs. But this is a very exciting EIP set because we have a really interesting headliner called Peer Das and the theme here is blobs, right? We're trying to scale the data layer of Ethereum through blobs and do it in a way that, you know, keeps it practical to run at home and to, to keep the decentralization going and keep the home staker alive and at the same time scaling, scaling the data layer, scaling the L1 there, there's a little bit of both in this upgrade and if you like we can dive into each of the IPS or kind of touch on them a little bit. We start with Peer dos. This is one dimensional Peer das. So the idea in Deneb two forks ago, so we introduced this blob layer right where we, you can post.
- [04:46]
Arbitrary data. It's called a blob because it's sort of undefined what it is. It could be anything, could be a picture of a cat, it could be call data or the, the batch data from an L2, which is more practically what we see. See some people, you know, playing games on like actual games on the data layer. There's something called Blobhouse which is kind of interesting. But really this peer DOS is about supporting L2 so people that want to build on the L1 and need the data availability layer that we provide. And so when we introduced this we said, well let's upgrade the Blocks so that people can buy six blobs. They're all the same size, I think 128 kilobytes. And you can buy up to six of them per block. And then everybody who runs a node downloads the blocks, the blobs and the blocks, downloads everything, retains everything for a period of time. And.
- [05:49]
You know when you want to start scaling this, you want to start increasing. And when you're asking more from the network, say if we went to 12 now, suddenly everyone has to double the amount, right. And that just doesn't scale very well. So there are techniques that we have in computer science where you don't need to store everything. Right. The novel invention in Piras is to use erasure coding, which is a fancy way to say if you have a subset of the data, let's say 50% of it, you can reconstruct the other 50% of it. This is technology that was really popular, I think in the 90s with compact disc players. Right. If you were like jogging with your disc player and it like skipped, what they would do is, you know, you, if it didn't read the disk for a moment, it has enough data to continue playing music. So we can use a similar idea. Instead of having all the data, everyone having all data all the time, you just have a little bit of it. And for a normal validator, let's say what I mean by normal is at home staker with one validator, they don't even need to retain 50%, they're only going to retain.
- [07:05]
Some part of that. I think they're going to have eight data columns and there are either 64 or 128, I can't remember. But they don't have to retain all of it. They're going to get a random number of those and they're going to sample. So they're reasonably convinced that, okay, most of the data is there. I'm convinced that it exists. So it makes it easier to scale the blob layer, the data layer, without having to impose these.
- [07:36]
Big hardware requirements. Right. You're not going to need more, you're not necessarily going to need more disks, disk space. So right away.
- [07:44]
When, when Fusaka goes live, probably is already live. If you're listening to this now, node operators, the, the blob count is still six, the maximum or nine, whatever it was in PETRA didn't change right away. So all of a sudden node operators are storing less data and achieving the same goal. That's a huge win. But right away we can take advantage of that. Say well, now let's increase the target blob count and the max blob count and kind of reach parity of where we were. So we'll see.
- [08:23]
The Fusaka fork happens on December 3rd and then on December 9th we have something called a blob parameter only upgrade or hard fork. And this is a sense that there's not a client update that goes out. Every hard fork, every upgrade, everyone has to like get their software updated. You already, if you've already, if you're on Fusaka now, you already have this built into your client, you don't need to update again. This will be the blob parameter only upgrade and that'll be on December 9th. And I can't recall what we go to. We go to. It just increases to oh, it increases to 10 as the target and 15 as the maximum. And then again a month later in January 7th, it'll increase again to a target of 14 and a maximum of 21. So that's a pretty substantial update to the data layer. We have a lot more capacity that's very interesting for L2s. So what does it exactly mean for an L2 user? Fees will go even lower, I imagine, which is kind of hard to imagine because fees are so low right now. And on mainnet I saw the gas price being 0.1 Gwei. I've never seen it that low in my life and that was amazing to see. But anyway, we're scaling and that's why it's so low.
- [09:51]
Actually part of Fusaka was that the L1 gas limit went from 45 million to 60 million as a client default. And because people are updating early, that already happened and fees went way down because there's, you know, now a lot more block space to use on the L1. That's really great. And then we're also scaling the data layer so L2 is benefit from that. It's pretty cool.
- [10:17]
C
That's I think for context for our listeners, Fusaka mainnet upgrade is happening on Wednesday, December 5th and we're recording this on Monday, December 3rd, two days before. So depending on when you're getting this episode, it could be that fees are even lower by the time you're listening to this episode because of the scaling improvements that are coming through Peer das.
- [10:46]
I want to double click on one of the things that you kind of mentioned, Preston, and you said that peer das, which is the headliner, the main feature in Petra or sorry, not Petra, Fusaka is one dimensional.
- [11:03]
Can you talk a little bit about some of the features that still have not yet been implemented for peer DAs to be fully for that data availability sampling to be fully functional because as I'm aware some of those benefits around being able to scale blobs, being able to increase throughput without impacting the home staker, that's still the goal even after Fusaka. Can you talk a little bit about.
- [11:34]
What kind of features are not actually enabled through the partial peer dask that's implemented through Fusaka and still needs to be done after this upgrade goes live.
- [11:43]
B
Yeah so what I mean by one dimensional is that when we have a blob we split it into columns as I mentioned before I think 128 and some you only need to. That's the one dimension that are split into columns and you retain a subset of that multi dimensional PDOS or the proto dank sharding vision is a lot more elaborate. I feel like I couldn't do it justice to explain it correctly. I'm afraid to misspeak but my understanding is that you can use data fraud from other blobs to reconstruct other from data columns from other blobs to reconstruct the blob in question. So you would be able to retain you know, less data and be able to reconstruct more. So that's kind of interesting but this kind of like is a building step towards that. And you know when we're talking about going to like 21.
- [12:45]
Blobs per block, I mean we, we want hundreds at some point. So this is you know there's still a lot of work to do here. This is a, you know a big stepping stone towards that. And to take equal use with the blob parameter only forks is that we can you know incrementally ramp up to that instead of like going on day one from.
- [13:08]
To going to a significant up update in blob capacity we can do it incrementally nice for multiple reasons like node operators have time to react if they're like hitting some resource limits which they shouldn't in, in this, this case because quite conservative and fe the fee markets are a little more. They don't have such a shock to it when it's like capacity just tripled overnight it'll be like over a couple of like in this case it'll be over a month and a half like six weeks. So that's pretty nice.
- [13:41]
C
Yeah some incremental upgrades. I mean to that point we were talking about how this before this recording recording how it's going to be the first time developers have shipped two major network wide upgrades in one year. Technically it's three because as you said there's the BPO1 hard fork which means you guys are shipping three upgrades in one year. And by the number of EIPs that have been implemented, this is by far the biggest year yet for Ethereum development. Petra was the largest upgrade by far with 12 VIPs. I believe this one Fusaka is the Same or similar. 12 VIPs.
- [14:21]
How significant of a milestone do you think that is that Ethereum developers are shipping this many features in this short of a time?
- [14:32]
B
It's huge. I mean historically we've moved quite slow by design, right? Like it's, it, there's just a lot of moving parts here. And the fact that we can get two in one year is really impressive because it means like people are finding a rhythm and like getting through. And what I'm hearing from my peers, other core devs are not hearing excessive burnout. Like this isn't like oh we just worked twice as hard because we were already you know working 110%. But something in the way it was organized just we able to do it on, on the Prism team we kind of have like an A and B team internally where like some people are working on like H Star already, some people working on glass and like and then while we're wrapping up Fusaka, you know people are jumping ahead so kind of leapfrogging each other. Like half the team is working on one fork and the next one so things are happening in parallel and I think that speaks to you know, Ethereum community and core devs want to move quickly. Like we want to scale, you know, we, we like to ship things and, and, and seeing you know, Petra was the biggest fork like of all time. And then we just, we're like you know what, let's do it again. And we did it again in one year. That's, that's, that's really impressive. And you know this upgrade hassle, just a lot of really exciting things like not only the blob parameter stuff but they're EIPs for like UX that I'm really excited about. Maybe we could talk about that.
- [16:01]
There's an EIP that adds a free compile for the elliptic curve that.
- [16:08]
Is commonly used for pass keys. So we, you know what if you said like I wish that everybody had a hardware wallet. Well now if you have a, a phone, an iPhone or Android, now you do because there's a cryptography chip in there where you have your private key. Like baked into the phone. So your phone is like the hardware wallet. And now that hardware can sign Ethereum transactions natively, that's huge. Like that's going to unlock like, like sign your transaction with your face, your face id, you know, that's going to be super cool. Or your thumbprint or whatever you people are using for pass keys today. You know, passwords are kind of going away and we're kind of moving towards this model where you have this secure enclave and some kind of like biometric. And seeing that for Ethereum is really cool. So that, that benefits L1 and L2. Everyone who's using the EVM and supports the CIP will see a benefit of, you know, user, user, user experience for sure.
- [17:11]
C
Any other particular impacts from the long list of VIPs in Fusaka that you think is important for L2 operators specifically to know?
- [17:22]
B
Yeah, so there are a few things that impact them. One of them being that, you know, as we're, as we're increasing the block size, what I mean by size, like the gas limit for blocks, there becomes risk for, you know, certain attacks like just filling with junk and stuff like that. So folks have advocated for an EIP that limits the gas for any particular transaction. So the new limit will be 30 million. And I don't think that will necessarily be an issue right away, but for some L2s, I could imagine they use a very expensive, like batch processing or transaction settlement through call data that could impact them. I mean they can, there's ways around it. Right. But that's something to call out.
- [18:15]
Mostly affects how L2s operate, not like end users won't really notice or care how it gets done as long as it's getting done. There are other things for L2s, like the deterministic proposer look ahead. And what this means, this EIP means, is that with the consensus layer, we don't know exactly who's proposing the next epoch until this epoch finishes. We have a good idea.
- [18:47]
But there's like, you know, a little bit of randomness that can happen. And so we, we can't make any decisions.
- [18:55]
Based on the knowledge until the first slot of an epoch. And so when you have sequencers that want to work closely with L1 producers, L1 block producers, you need to have that deterministic capability of predicting well what's going to happen in the next 12 minutes. And that way you have like a little bit of advanced notice. Like maybe there's some like base sequencers or someone who's like working with.
- [19:25]
Validators to get their stuff committed in a particular order. Imagine you wanted to do. You want two L2s that batch their things together so they can do cross chain intense or something like that. People can get creative with the idea, but having that gives a little bit more flexibility on what you can build for L2s. So that's interesting. Another impact for L2s is the fees for blobs. Historically we have made a huge fumble in the fee market for blobs where like typically or for the longest time they were being purchased for like one way. Like the, or one way, probably like the bare minimum you could do. And this didn't. This is just like a, like a naive assumption of like, oh, we're going to find equilibrium in the fee market. But one way or one way, whatever it may be, a small number doesn't even reflect the computational cost to process a blob, right? So we're kind of like giving this away for free and not even charging what it costs the node operators to, to process.
- [20:42]
So now there's a new EAP that ensures that the minimum fees are at least enough to cover the execution cost. And that way the fee markets are more predictable and they're not like, like, you know, it can still be very, very cheap, right? But it's not going to be like free anymore, which just makes sense. You know, I don't think, I don't think L2 fees will really notice this much, but the narrative of like L2s eating the L1s at lunch kind of goes away a little bit because you know, at least they're going to be paying for what they're using, which is fair.
- [21:22]
C
That's quite a lot of different EIPs that L2s do need to be aware of. And as I understand, because I've been tracking like the developer calls, there have been moments in the lead up to this mainnet upgrade for Fusaka where L2s were kind of caught off guard by these different EIPs and their impact. Specifically on the, on the topic of like how peer das, the main headliner feature is going to impact them. And I think even before this call or this recording, which again we're recording like just two days before the upgrade, um, I think I saw someone from off Chain Labs asking in the discord whether there would be kind of like a limit in the geth client around how many blobs you can attach for your transaction to be even valid and like kind of functionality there changing that was unexpected. Do you think L2s are prepared? Like, are you worried at all that there's going to be any L2s that. Yeah. Unexpectedly find that maybe they haven't updated their proofs for like KZG proofs for BLOB transactions. And they should have, but they didn't and kind of like this, this, this sort of like unexpected ways in which their operations may not work after the upgrade.
- [22:42]
B
Yeah, that's a good point. It's a good question too. The Blob transaction, like the transaction you do to purchase blobs, it does change, right? So if you haven't supported that, it's not going to work. I think that L2, you know, the way that we go about conducting these upgrades is that we update the test nets pretty well in advance. Right. So I think like Sepoy was updated like over a month ago, maybe two months ago. And I heard that that's, you know, when people found out for the first time, like, oh, my thing is going to break and I need to fix it right now because it's going to break and in minutes and you know, a short amount of time. That's kind of the purpose of testnets. Like maybe it could be, it certainly could be better communicated saying like, here are the breaking changes coming up. I think the EF blog post did a pretty good job of outlining these. You know, there are things changing with like opcode, gas, cost and so they're like little tweaks that it's kind of hard to, it's kind of hard to communicate. Every scenario in which this is a breaking change.
- [24:03]
People do really creative things. You can't predict all of it. For the, the major L2s, I'm confident that.
- [24:14]
They are well aware of what's happening and that when Fusaka activates, it's not going to be like, oh, your favorite L2 just stopped posting to the L1.
- [24:28]
I, I don't expect that to happen. Maybe, maybe it could, but I believe that the people running these operations are, are paying some attention because it's, it's, you know, we've been talking about it for a few months and like it's been in the testnet for a little while and like, if you haven't been running your chain in a testnet for the last six weeks and maybe you don't know, but people should know by now. Right? That's what I'm thinking.
- [24:52]
A
Hey, founders and developers, if you're looking to bring on chain trading to your product, wallet or platform, check out the new Uniswap Trading API from Uniswap Labs. It's your plug and play gateway to global on chain liquidity. No deep crypto experience required and no need to manage complex integrations or ongoing maintenance. With the Uniswap Trading API, you'll get enterprise grade on chain execution combining both on chain and off chain sources for the most competitive prices. Simply put, more liquidity, less complexity. And this isn't just any API. It connects directly to the Uniswap protocol which has securely processed over three port trillion dollars in total volume with zero hacks. So stop worrying about liquidity infrastructure and focus on building your product. Get access to the same liquidity that powers billions in swaps through one powerful API. Visit hub.uniswap.org to learn more. Mantle has entered a new phase as the distribution layer connecting TradFi and on chain liquidity. To accelerate this vision, the Mantle Global Hackathon 2025 is inviting developers to build scalable RWA and DeFi products. Why build on Mantle? It's an ecosystem built for builders. You get direct access to Bybit's 7 million plus users for potential listing exposure, support from the $4 billion mantle treasury and mentorship from top VCs like Spartan and and Animoca Brands. With six tracks prioritizing RWAs and RealFi and a $150,000 prize pool plus grants, this is your chance to deploy on a high performance modular L2 register. Now the link is in the show notes.
- [26:42]
C
Okay, so L2s are are prepared for the upgrade. They had over a month to prepare on those tests nuts. Which is good. One other concern is do you think that L2s are going to be able to use peer DAs to its full capability because of the lack of features around peer DAs as it relates to things like backfilling? I recently learned about this actually from a member of your own team, Preston, that backfilling is a really important feature that will allow nodes to retrieve data from blobs if they accidentally go out of sync with the network. And this is a feature that is not ready in all consensus layer clients. If I if I understand correctly.
- [27:34]
B
Yeah, yeah, we think it's a really important feature. So backfill. What it means is, you know the typical way people bring a note a new node online is they sync from a checkpoint, usually the last finalized checkpoint. Because that's really what you care about. You care about the unvinalized stuff, stuff that just recently happened. So when you start from the checkpoint you don't have anything that happened before it. And syncing from Genesis is no longer viable. There are actually Attacks you can do to trick people about what's happening with the state of the world. So, right. Syncing from Genesis is not recommended. It also takes forever. Actually running an experiment this month to see how long it takes and I'm in like week number three. So not recommended. But Altus, they, they need to retain these blobs, this data, usually forever. They kind of don't. They want to have all of the blobs since blobs existed, and they want to have all the data columns in pure OS sense. They exist there. They want everything. So we're thinking about bringing a new node online. What do you do? And there, I mean, there are techniques, you know, make your own backups and whatnot. But how do you get it directly from the network? Well, you start from a checkpoint sync and then you do an operation called backfill, which is going backwards from that checkpoint and filling in that data that you're missing. In particular, you want blocks, and you want blocks address data columns. This feature we've been working on at Prism for several months now. It's been under heavy review. It's been one of the biggest features we've ever implemented. And just over the holiday weekend, we were still putting in the time to get it working. And I'm happy to say that it works now. And that's going to be the next release, 7.1 for Prism. I'm sure other clients will have it soon, if not already. It's pretty important.
- [29:41]
But there's another part to this too. As I mentioned earlier, that you need 50% of data columns to reconstruct a blob. And a default client only retains 8 out of 128. So we have this other feature we're releasing we're calling a semi super node. And what it means is you'll retain exactly 50%. You don't need 100%. You could, but you just kind of like have redundant data. In that sense, you could be a super node, which is just, I'm going to retain everything forever. I want it all. Maybe some of those people exist, but you actually only need 50%. So L2s. The recommended configuration is you can checkpoint stake with backfill and you should be running this semi super node for flag if running Prism, so that you retain enough blobs enough for the data columns that you can query any blob that you want.
- [30:39]
That you've already synced. That's pretty important when they want to recall the data. And if you only had the eight data columns, you have to then go Ask the network and the network, the default for most clients is I'm only going to retain the data column for the minimum amount of time that I need to, which is 4096epochs. So if you want historical data forever, you need to have something there that in, in our case that also turns off, I believe that would turn off any pruning because, you know, it's like at home sticker. You really only want to, you kind of want to push the limits of what's the minimum amount that I need. So you can actually delete old blobs and old blocks and old things after certain points. But for the people that want it, semi supernode or supernode flags will be available soon and you can retain all that data forever.
- [31:32]
C
That's really cool to hear that those features are coming. And just to confirm these features are hard, fork independent clients can just implement these features asynchronously from one another.
- [31:46]
B
Yeah, all the building blocks will be there in Fusaka and we're just.
- [31:52]
Stitching them together to say if I.
- [31:56]
Start backfilling, which backfill already exists for blocks.
- [32:00]
And blobs but not for data columns. So that's the kind of tricky part is like you need to go find. Because like the way it'll work is you need to find a peer that actually has that data column because the peers you have may not have it. And so you're kind of like sampling everybody to find it and yeah, that's pretty much ready. We've been testing for weeks and I'm finally happy with it. So we're going to ship it soon.
- [32:23]
C
Do you wish in hindsight, looking back that you guys had had more time with Fusaka, like had more time to prepare these features, test these features? Like, I, I think that was a big topic of discussion and debate throughout these last couple months. What's your take, Preston?
- [32:46]
B
Well.
- [32:48]
More time comes at a cost, so if I could have time for free, I would take it. Right. Like, we were certainly a little stressed at times and even right now, everything's done, but it's still a little, kind of get a little nervous every time there's a hard fork. You've been testing forever and you feel really good, but it's, it's just still a little nervous. A little nerves there. So a little more time would have been nice. Okay. I guess I expected that this was going to ship in January or like Q1. I thought it was a little silly to do anything in the holiday season. Like in the US we just had Thanksgiving last week and now we're in a hard fork and then the end of year holidays are coming up and people are taking time off to to rest.
- [33:39]
So yeah, I would have liked more time, but what I what is the cost? Right? Like Ethereum needs to scale and use the scale now we have a lot of really exciting activity happening. People are like finally looking at Ethereum as like a legitimate place for real finance. So.
- [34:00]
I hope that my peers were not feeling too stressed out. I empathize with you. It was this was another huge fark in a year in which we already have One more time would have been nice, but we also need to ship and ship fast.
- [34:14]
C
I was under the same impression as you, Preston. I totally thought this was going to be a Q1 upgrade and then it just was not. Which again like you said, is not a bad thing so long as the upgrade goes smoothly and delivers on the impacts and the features that it's supposed to deliver on.
- [34:34]
One other kind of meta question around the shorter timelines for upgrade upgrades, I did notice there were a couple clients, at least four in the last seven days that had to put out releases pretty last minute close to the fork date. There was some discussion among developers of, you know, how safe is it really to ask node operators to be upgrading to a critical fix just a couple days before the actual hard fork date, as in the case of the Nimbus client. Yeah, I mean for clients that that are shorter resourced, you know, they don't have as many perhaps developers as the Prism team to be working on things in parallel. Do you think the shorter timelines for upgrades means less client diversity? Like smaller clients just will not be able to keep up or will be.
- [35:22]
Perhaps? Yeah, like less tested, more buggy than the more well resourced clients that are able to keep up with this faster, faster development timeline?
- [35:36]
B
Well, I would say that a release between the announcement of final releases and the main releases or the main upgrade time is pretty common. In fact, we would have issued one last week if we had backfill already. There are some fixes in there, nothing like Team Urgent. Usually this stuff is found in testing.
- [36:01]
But you know we're constantly finding things that like to improve this log message is confusing or there's no action to take trying to like make it easier on like oh maybe there was a bug with like something important because all features are important or we shouldn't have them. There's a some bug is something important but it's not like critical to the safety of the chain. So.
- [36:25]
Those like really Urgent ones, like hot fix. Or like, if you found like a bug that would really, really mess stuff up, you need to get out right away. And I think whether or not that's safe or not.
- [36:40]
It'S kind of hard to say. You know, I. Ideally you would want your client team to, to issue releases and quickly and like, when they find bugs, fix them. Like, bugs happen. Like, you know, whether or not your team is large or small, it really does not have much in the way of like, bugs. Right? Like, in fact, you know, you can, you can have, you can have too many cooks in the kitchen, which can be a bug risk. Like where folks are.
- [37:10]
No one's really sure what's going on because every, everyone has their like, small piece of a puzzle they've been working on. So when they're like trying to figure out or some, and then someone leaves on the team and you're like, oh, I don't know how, like, I don't know how P2P works, or like, I don't know how the database works. Like, you kind of have risk there when you have a smaller team. I feel like those folks sometimes can be more streamlined and then like, I kind of have a better understanding of everything looking more closely and.
- [37:38]
A bit more methodical. So it's not like a cut, like a black and white of like a fast. A bigger team could go faster. It's not always the case. In fact, like, you know, we've. We've over the years, like always kind of fluctuated between like 6 and 10 people. And.
- [37:56]
It'S not a big difference between 6 and 10. Like, there's. We have more capacity to get things done, but there's so much like collaboration. Like, if we had 20 people, I don't think we could get in twice as fast. You know.
- [38:09]
It does help that we are able to split up a little bit and split the work and kind of get ahead. We kind of, I think on our team or in my personal experience, feel a lot of pressure about being left behind. Like the scenario you described of like, oh, this client, minority or otherwise is not going to have this feature in time. What if we ship without them? And that's just like a terrible feeling, right? Like you're trying to get your stuff done as fast as you can and if people are like, oh, let's just leave, let's just leave without them and see what happens. So I feel that, like, kind of like pressure of like, I need to get it done. And when you have that kind of pressure, sometimes you can have bugs Bugs happen.
- [38:52]
But I don't think that a minority risk, I mean a minority client is inherently more risky than a majority client or a more well funded client. It just kind of depends, you know, just really depends.
- [39:07]
C
That's a good point though also that a good point about the minority clients aren't necessarily the ones to move slower than majority clients.
- [39:17]
About. But it's also valid the concern around being left behind of some of the decisions were on the timeline for mainnet was done even though certain clients were not ready with their mainnet releases this time around.
- [39:31]
Looking back, is there anything at all that you think should have been done differently with Fusaka's.
- [39:41]
Preparations, Main Net preparations?
- [39:49]
B
I don't know. I actually think this one was a pretty good one. I think this one went pretty well. It's always things we could have done differently. Like we have things in our team that we keep making the same mistakes and a mistake being like.
- [40:05]
Well, our problem is that we'll make a big change. I'll just implement Fusaka all at once and then you ask someone to review it. You're like, dude, this is like 10,000 lines of code. Like I don't want to review this. So if we have more time, I think people would take a little bit more to split things up and to make like smaller changes and then like, you know, those can go out more quickly like piecemeal. Get it done in piecemeal and have more time for documentation. Although like really this fork felt like it was really well done. Like we learned a lot from that. Manu, from our team, he's was our Peer Dust champion and he written this like right away he wrote this.
- [40:56]
Document, this wiki page, it's called peer das.net and I, I reference it all the time because I'm like how do, how does peer work again? Like I have to keep like recalling that, that, that information and the fact that he took the time like upfront to write this all down. You need review, implementation, testing so much easier this time. Like because everyone kind of understood what's happening and you know, while Fusaka had the same amount of EIPs as Electra, I feel that the number of consensus changes were smaller. Like really this one big one which is peer to us and then like you know, deterministic proposal book ahead. So many small things that you know that and where like Electro had like consolidations and all this like other big things that were like some refactoring that was a really painful like it just touched way more of the. Because there's this layer that P does P is like let's just work on blobs.
- [42:00]
Just felt a lot easier this time. I don't, I don't know. And maybe that's why we're able to get it done in December and not in January.
- [42:09]
C
That's surprising. I didn't know that it touched less parts of the consensus layer and was perhaps easier to ship than the Electra upgrade because from my perspective, non technical view I'm like oh it's the same number of the IPs are similar still like you said, Peer Desk is a major shift. In the last couple minutes of our time together I want to talk about what people should be looking out for in terms of mainnet activation. So we talked about its impact on L2s, we've talked about other EIPs and Fusaka as well as the preparation process.
- [42:49]
And thank you for juggling my hard questions around the timeline for it. But yeah, for our listeners that are going to be trying to, you know, watch it happen live, what would you say is the best way way to watch the Fusaka upgrade happen in real time?
- [43:07]
B
Run your own node and if that's not for you there, there are like live streams I think like sort of EF or the Ethereum YouTube channel is going to have something, surely something on Twitter. Spaces, X spaces, whatever you want to call it. Those are going to be places to be and.
- [43:27]
Usually there's a call and someone sings a song sometimes it's pretty fun. Like I really do enjoy the actual fork when it happens although it is a little stressful and we're always a little nervous. It's still a fun time to get people together and like see folks on, on the stream and talk about it, what it was and then you know the fact that we switched to a time based system with proof of stake and we can schedule these things very reliably instead of waiting for a block difficulty. So becomes a lot more fun that way.
- [44:02]
C
Yeah, we'll definitely link the live stream into the show notes of this episode. I'll send over a couple of show notes to include for this episode.
- [44:14]
I mean on the topic of your nervousness around Fusaka like compared to in terms of the technical risk, like the riskiness of Fusaka compared to prior upgrades. Like how would you rank it? Are you more nervous this time? Less similar.
- [44:30]
B
For this one. I'm less nervous in the sense that it touched a lot less of the software and Electra had changes to attestations and the beacon state and a lot of different things A Lot more operations. This one's a little bit more simpler in this sense. I think that our friends at the ETH Panda Ops, these guys are doing incredible work testing and building confidence. So the more updates I see from them, I feel really good that, you know, our client is working well with other clients and they're testing it and they're giving us feedback constantly. So the, you know, the systems that we have are constantly improving. So I feel pretty good. And you know, the timeline that we have where we have months of time testing, you know, Fusaka's been live somewhere in a test net for months already and nothing bad has happened. So going to mainnet will feel very similar. Usually these events, the upgrade is very boring because nothing happens and that's the way it's supposed to be. So yeah, always nervous because there's, you know, it could be a bug hiding somewhere. But we actually do, I think a pretty good job of finding those well in advance and keeping the bugs out. So. Feeling good?
- [45:42]
C
Good. I'm really hoping for a very uneventful evening on Wednesday myself. It's going to be like 5pm local time for me, which is great because the merge I think was at like 4am yeah. Which was awful. Would you. I mean, obviously for me, some of the things I'm looking for is like network finalization after the upgrade. Are there any other kind of important indicators of a successful upgrade that you're going to be watching out for either immediately after the upgr or like a couple weeks or months after to know that it was a hit?
- [46:18]
B
Yeah. Well, we'll want to see right away that the new Blob transactions are coming in. People are buying blobs, they're getting propagated through the network and they get saved the disk. That's going to be really key. That's the main feature. And then of course, seeing that data finalize is kind of like the ultimate test. Right. If we fork to Fusaka and there are no blobs at all, it's. And if and it finalizes, that's kind of not quite the success metric. We need both. We need to see it finalize with the data that we're looking for, I expect it will be perfectly normal. Maybe, you know, Maybe there's an L2 that didn't update, so there's slightly less volume of blobs coming through, but there will still be some. And we'll see you finalize and it'll be interesting to see in the coming months when we do the blob parameter only updates like that's another exciting hard fork that will happen. And seeing the Blob fee markets, you know, stabilize around that. It's going to also be interesting to see how people are pricing blobs.
- [47:24]
When those updates come.
- [47:27]
C
Yeah, those are good flags for our listeners that want to keep tracking the upgrade even after it goes live. One last question on the blob parameter. Only hard forks that are going to be coming up after Fusaka, how on our toes should the Ethereum ecosystem be for those forks? If Fusaka goes well, do you think developers are going to have to be able to rest easy over the holidays in between the blob parameter hard forks? Talk me through a little bit of the risk assessment of the BPOs that are coming up.
- [48:01]
B
Yeah, I think if you're a node operator, like a validator, it's going to be a non event for you.
- [48:09]
You'll want to maybe check in on your hardware usage the next day, kind of like monitoring it. You know, the thing is that you, when we increase the Blob capacity, it's not going to like fail spectacularly. You're going to slowly see your disk usage increase. So you'll kind of want to pay attention to that. Although the way I understand the math that we have now is that these updates are still like at par with what you were operating today. So you shouldn't need to, you know, go out and buy a hard drive right now. I think you're going to be fine. L2 operators who want to be monitoring those updates just to see the exciting drops in BOB fees, you know, they'll plummet right away when the capacity goes up significantly. That'll be interesting.
- [49:04]
Yeah, I mean, you're not going to need to update your clients. So you know, if, if things are working smoothly for you and you're not in need of these exciting features, I discussed the backfill. Then you may not have to update your node for the rest of the year and you can just kind of coast through 2025 into next year until.
- [49:23]
C
The next Glamsterdam upgrade, which I'm sure we will talk about when the time comes. Yeah, well thanks so much Preston for walking through the entire Fusaka upgrade with me on this episode of Unchained.
- [49:37]
B
Yeah, thanks again for having me. It's been really fun.
- [49:41]
C
Yes. And I hope everyone who is watching to this, watching this, this guest episode of Unchained also found this episode very informational and beneficial to getting you guys prepared for what to be looking out for and expecting from the next major Ethereum upgrade. Fusaka which will soon be a thing of the past. And thank you to the Unchained team for letting me take over for this episode. I wanted to note that if you want more regular deep dives on protocol development for Ethereum, I have a weekly podcast ready for Merge and I also have a bunch of newsletters on my substack. Christine D. Kim.substack.com There is also an interview with Preston on the substack that just goes into his journey as a core developer, so you can find all of that in the show notes of today's episode. We'll also include links to the Fusaka livestream and the Ethereum foundation blog posts for Fusaka. If you are a node operator on Ethereum and still have not upgraded, there will be links for you in today's episode to yeah, get more information and upgrade. But yeah. So thank you everyone for listening. And thank you to Unchained for letting me host. Bye everyone.
- [51:02]
B
Bye. See you.
- [51:05]
A
Unchained is produced by Laura Shin with help from Matt Pilchard, Juan Aranovich, Margaret Curia and Pam Majumdar. Thanks for listening.