What’s Going Into the Pectra Upgrade?

On what is going into the Pectra upgrade, we're going to talk about all the EOPs that are going into the Pectra upgrade. Quick disclaimer before I start, everything I'm about to say is all informational, for informational purposes, should not be construed as financial or investment advice. Before we get into what's going into Pectra, the question that I get asked the most is when Pectra is going on to mainnet. So I'm just going to get that out of the way so we can get into the technical stuff. This is a very tentative timeline analysis, and everyone's taking pictures already.

When people ask me, when is Pectra going to happen? I say it's too early to tell because it's true. Pektra is still in very early stages of its development. Specifications are changing. The scope of Pektra even has not really truly been finalized quite yet, as we'll talk about.

But through this process, one of the things that you can learn is how upgrades get developed, how upgrades get tested, and eventually make it onto main net. So initially what happens is developers decide on a couple of EIPs to include in an upgrade, and then they implement those EIPs onto private developer-focused test nets called DevNets. And developers have already launched a couple of DevNets already for Pektra, so these EIPs have already undergone a couple of rounds of implementation, and developers have noticed edge cases, have noticed various bugs that they want to fix, and they iterate. They iterate on these EIPs by launching new DevNets. DevNet 4 was launched last month, October.

And this doesn't usually happen, but developers, very specially for this entire conference and for everybody in the audience, launched the first public Pektra testnet. This month, it's called Mekong. So you can go and interact with some of the EIPs that are going to be in Pektra early on. It's based on DevNet 4 specifications. But please note that those specifications are changing.

There is a list of changes, specifications changes to the EIPs that developers already want to include into Pektra DevNet 5. So there's things like BLS precompile repricing, a new EIP that hasn't been implemented into DevNet 4, but developers are aiming to implement it in for DevNet 5 or a future upgrade. So Pektra specifications are changing. I foresee multiple more dev nets still to go before specifications can really be frozen. And the other part that's really important for the Pektra upgrade in its progress to mainnet is for the scope to be finalized.

For all of the EIPs going into Pektra to be decided upon with developers. And there is one EIP. It's not really an EIP yet. But it's the blob capacity increase. That is what developers have not yet formally included into Pectra.

But it seems as though they're likely to include a blob capacity increase, some kind of a blob capacity increase into Pectra because of the fact that they have recently included this EIP, which we're going to talk about, which introduces a mechanism to be able to update the blob gas target and the blob gas max dynamically through the consensus layer, rather than having those parameters hard coded in the execution layer and the consensus layer. So the addition of that mechanism into Pectra suggests that developers are doing all the heavy lifting of trying to implement a change to the blob capacity increase or a change to the blob capacity in Pektra. But developers have not formally decided or formally included that increase. Right now it's a target of three and a max of six. They're not sure if it's going to be an increase of four or five or six.

So ideally, hopefully, developers will be able to finalize that early next year. And I think as the specifications for the other Pectra EIPs become hardened, more finalized, it puts pressure on developers to kind of activate them on main net. And in order to do that, you have to ensure that the scope of the upgrade is fully complete. So strong, I guess, like thinking or reasoning that the Pectra scope will be finalized by early next year. And then once it is finalized, you start testing whatever new EIPs that you've implemented, the full scope of the Pectra upgrade, you test that and battle test it on a couple more DevNets.

I envision, say, you know, until maybe DevNet 6 or 7. And then once the Pectra specifications are frozen, they are ready to go, all the edge cases that developers can find on DevNets have been found, they will then release the Pektra specifications, developers have budgeted about two weeks between public testnet upgrades. In kind of rare occasions, developers kind of shrunk that timeline down to even just one week between testnets. But because of the size of Pectra, I imagine that developers will want to take the full time to see how the Pectra upgrade fares on public testnet environments. So I am budgeting roughly about a month for the Sepolia and the Holesky.

Holesky, I don't even know how you say it right, but Holesky. Thank you, sir. Yeah, so that's going to happen. And I'm budgeting about a month for that. And then after, that's when you can finally have the mainnet activation.

So given all of the information that I know right now and the progress that developers have made so far on Pectra, my best analysis and guess is that Pectra mainnet will realistically happen next April 2025. Again, this is very tentative because a lot can change between now and April. Development happens on a week-to-week basis. Developers are on these ACD calls talking about this bug that they didn't expect in this EIP. Or this new EIP that they do want to add into Pektra now.

So a lot of things can change this timeline. But looking into my crystal ball, there you have it, my timeline. Let's move on to what is the meat, you know, the bread and butter of this talk, which is what is going into the Pectra upgrade. There are 10 EIPs that are going into Pectra. And four of them are focused on the execution layer.

Oh, my gosh, the print is so small there. EIP-2537. It is a new precompile. Yay. a new precompile, yay, new precompile into the EVM, BLS12381 curve operation.

This is a new cryptographic signature scheme that smart contract developers have been asking for for a very long time. This is an EAP that was created in 2020. And at the time, dApp developers were like, we really want this because it would give dApps, certain dApps that are relying on zero knowledge cryptography, stronger privacy guarantees, potentially increased security and scalability. I believe BLS signatures, that signature scheme or that aggregation is also the signature aggregation that happens on the consensus layer for validator attestations. This EIP is a long time coming.

And so I think one of the concerns around this EIP is, are there still apps that are waiting for the BLS precompile? And are they going to use it when that precompile goes live? So kind of an open question. But if you're in this audience and didn't know that the BLS precompile is finally coming, it's coming. And maybe, you know, you have an app that hasn't already moved on from this vision and can still utilize this precompile in some pretty cool ways.

So it's going into Pectra. EIP-2935 serve historical block hashes from state. This one introduces a change to the execution layer such that proofs of historical blocks can be generated from the state. This does have some near-term benefits. So it has some benefits for light client syncing, has some benefits for smart contracts that may want to utilize data about the state of a prior block directly through the EVM.

You can't actually do that right now. But those near-term benefits is not the reason that this EIP was included into Pektra. Because clearly those benefits are a little bit iffy. Not like super important, I guess. But the main reason why that was included into Pektra is because it's a prerequisite for Verkl.

And Verkl is this major overhaul to Ethereum's structure for state data on Ethereum. That developers had thought that transition was going to happen right after Pektra. So they're like, oh, you know, Fusaka, this is when Verkl's going to happen. Oh, well, we need this EAP if we're going to do that Verkl transition. But turns out, as we're going to talk later in this presentation, Verkl's not going to go into Fusaka, or at least that's not what developers are expecting right now.

They've punted it out to another upgrade. But it's still there. Developers did implement it and it will have some near-term benefits. But the primary reason for it is as a prerequisite to Verkl, which, you know, could happen down the road. And if it does, you know, this stepping stone has already been checked off the list.

EIP-7685, general purpose execution layer requests. This is an EIP that doesn't really introduce new features to Ethereum. It's really an EIP to support other EIPs in Pectra. So in Pectra, there's a couple of other EIPs where the execution layer will be able to pass way more messages, different kinds of messages to the consensus layer that it couldn't before. The execution layer, smart contracts on the execution layer will be able to trigger like validator withdrawals, consolidations, deposits.

And rather than implementing these new messages, these new communication channels, all in a separate kind of unique fashion, the implementation of these generalized, these execution layer triggerable requests, the implementation of all these requests, instead of doing it in kind of like a siloed fashion, why not create like a generalized structure, a generalized bus to house these requests? It will be easier to test, easier to implement across clients, easier to kind of standardize, especially if developers want to introduce new types of execution layer triggerable requests. So Geth developer, like client, he was like, I think this would be a good EIP to add. Once developers started implementing those other EIPs, they're like, oh, actually, this is something that would be pretty useful. So that's why EIP 7685 is in there, an EIP to support the other EIPs.

EIP 7702, this one's kind of, I guess, an exciting one. A new transaction type is coming into Ethereum, and this transaction type is going to temporarily allow a user-controlled account, an EOA, externally owned account, to have greater flexibility and enable features like some that I think many people in the audience have been waiting for for a while, to enable EOAs to have features like transaction batching, sponsored transactions, conditional transactions, delegated security. Pretty cool stuff. Like you're thinking, oh my gosh, is this like the account abstraction vision coming alive on Ethereum? No, it's not.

It's a baby step. So it's kind of like a baby step to seeing how this will improve the user experience. It is cool that some kind of temporary functionality that you'll be able to create some kind of temporary new flexibility into EOAs. But really it's an early step to see what the real roadmap to true native account abstraction could look like on Ethereum. This had quite a bit of debate in terms of how developers should take that first step.

A lot of controversy of this one getting in and its design. But it's in there. And I'm pretty sure of all the EIPs that developers want you to interact with and kind of test on the Mekong testnet, this is probably high up on the list. You know, trying out this new transaction type. So if you're on Mekong, you know, throw developers a bone.

Try it out. There are six others. These ones are consensus layer EIPs. I'm going to run through these really quickly. Because after me there's going to be some talks that go deeper into each of these EIPs.

So this is just, you know, summary overview. EIP 7742 uncoupled blob count between the consensus layer and the execution layer. This one is the most recent EIP to be included into Pectra. Developers, like I said, was considering should we include an increase to the blob capacity? And if we're going to do that, currently the blob capacity is hard-coded into the execution layer and the consensus layer.

And the hard-coding of these constants are all kind of different in all the clients. And so updating that hard coding is not as easy as some may think. So creating a mechanism to kind of be able to change the blob capacity and have it dynamically set by the consensus layer will ensure that in the future developers can easily change the blob capacity of Ethereum if they want to. And ensure that that kind of upgrade, it only requires consensus layer changes, doesn't require a change to both the execution layer and the consensus layer. So, yeah.

But it's like heavy work up front, right? Because the mechanism doesn't exist right now. Once the mechanism exists, yes, it will be easy to use that mechanism increase, the blob capacity in Pectra, we should really get started on this mechanism sooner rather than later. And so developers were like, actually, yes, other developers on the call, on the ACD calls I'm talking about. They're like, you know what, that's probably a good idea.

So that's why it was included. Developers have not decided on what specifically that increase is going to be quite yet. Let's dive deeper into some of these other ones. EIP6110, supply to validate deposits on chain. Vitalik, he was like, woohoo, in the main stage talk, like the merge happened.

The merge did happen. And Ethereum is more mature as a proof of stake blockchain. There are certain security assumptions that can be relaxed now. And one of those security assumptions is an additional round of voting that happens every time you deposit a 32 ETH on the Ethereum 2.0 deposit contract.

There's an additional round of voting that happens on the consensus layer side to verify those deposits. This EIP removes that additional round of voting on the consensus layer side, ensures all the deposit validation happens on the consensus layer side ensures all the deposit validation happens on the execution layer. This has some benefits for validator UX. It will shrink the time between when you deposit your 32 ETH and when you see the validator actually be activated on the beacon chain. EIP7002, execution layer triggerable withdrawals.

This is very good for staking pools. Right now, validators, if you want to fully withdraw a validator, the node operator that controls, that operates that validator needs to withdraw, they need to use their withdrawal key to fully exit the validator. But through the CIP, smart contracts will be able to initiate those full withdrawals. So it's kind of a trust assumption that you can now remove from staking pools. The likes of, say, like Lido, Rocket Pool, other smart contract-based staking pools, you can ‑‑ those smart contracts can now trigger full withdrawals of validators if they wish.

So a very nice feature for trustlessness and improving the, yes, I don't know, like resiliency, yes, resiliency of smart contract-based staking pools. EIP-7251, increasing the maximum effective balance. I have written so many reports on the problem of Ethereum's growing validator set size. This really is an issue. I guess, you know, when developers were thinking about the beacon chain, they did not expect the validator set to grow so quickly and for the peer-to-peer network of Ethereum not to be able to handle 1.

5 million validators. I think we're at like 1.2 or 1.3. Somebody can check me on that.

But there's a lot of validators, a lot of active validators, a lot of messages being passed around on the networking layer, and it's too much. It really is too much. So it's straining nodes, and left unchecked, it would be a major problem for the health of Ethereum. So EIP-7251 is designed to encourage validators to consolidate their ETH and have a maximum effective balance higher than 32 ETH and reduce the number of active validators on Ethereum. That is the goal of EIP-7251.

Let's see how quickly it is adopted once Pectra goes live because that, you know, depends on all of the staking pools and stakeholders of the staking community really, you know, getting it together, okay? So EIP-7549, move committee index outside attestation, kind of like a restructuring, refactoring of the way that attestations are aggregated to make blocks, or to reduce the networking load of Ethereum. Again, see, there's clearly networking pains, and save node bandwidth. And kind of a quick note about the CIP, developers when they were including it in Pektra, this is a great change, clearly has wonderful benefits, an easy one to go ahead with. In practice, though, turned out to be a lot harder to implement than expected.

So sometimes that's the way the cookie crumbles. Wow. I cannot believe I only have two more minutes. Okay. So in like the outlook, if you know, I blazed through that really fast.

Don't worry. In summary, Petra is a mixed bag of updates. It's going to do three things. It's going to fix critical shortcomings of Ethereum as a proof of stake blockchain. Think about max EB, right?

Like that's a critical fix that needs to happen because the validator set size can continue to grow unchecked. Improve the user experience, right? We're talking about, like, the new transaction type, making it always more flexible, some improvements for more trustless designs for staking pools, etc. Some minor UX improvements there. And number three, Ethereum's data availability capacity, increasing that.

That hasn't been formally included into Pectra, but again, seems likely. Moving on. Okay, here are all the EIPs that were removed from Pectra. This is kind of like a first-time thing for an upgrade to have so many EIPs removed from it. The first one is PeerDAS.

Honestly, there was going to be a much bigger increase to data availability capacity in Pectra. Initially, when Pectra was being scoped out, PeerDAS is going to allow developers to increase the blob target of Ethereum, not from like three to four to like four to five, but like by multiples more without impacting greatly the bandwidth consumption and the computational requirements of running an Ethereum node. But it's still in research and development phase. It's still being developed. And these other 11 code changes as a bundle are called EOF.

It's this major update to the Ethereum EVM. And both of these EIPs, all these EIPs were initially included in Pectra, but they were being tested on separate devnets. So you had the Pectra EIPs that were moving along, progressing, starting to solidify, starting to become more aspects of it were starting to become more or less finalized. But PeerDAS and EOF, there were developers thought that it would require a lot more time to get them really ready for mainnet activation, and developers did not want to delay the activation of the Pektra EIPs from getting onto mainnet, which is why one of the reasons was they wanted to get Pectra EIPs out sooner. So they said PeerDAS and EOF clearly needs more time to be worked on.

We'll pump that to another upgrade and not hold back these other Pectra EIPs from mainnet. Another reason is this is a lot of EIPs in addition to the other ten that I talked about, so lots of risk, right? With the interdependencies of the code, trying to implement it all at once. This is a lot of work and time for the testing team and the client teams to be able to ensure there aren't any bugs. So lots of reasons for two, I would say, actually main reasons for why these EIPs were removed from Pectra.

And now they are moved to Fusaka. So again, I have Verkl up there because Verkl was initially slated for Fusaka, but then now it's not going to because developers have given a soft confirmation that EOF and PeerDAS are going to be in Fusaka. But again, obviously, changes happen. In the moment, developers should be able to reassess priorities and make decisions accordingly. So it's unlikely, but there's a non-zero chance.

Anything could happen. Verkl is not in Fusaka for now. And EOF in PeerDOS for now is in Fusaka. And there's a couple other EIPs that I think developers will reconsider for inclusion in Fusaka once developers have the bandwidth to really think about it and give their full attention to Fusaka after Pectra. These are some of the other ones that were considered for Pectra but never made it in.

But now there's more time for these other code changes to be worked on. They could be a lot more ready for implementation six months from now than right now. So there's like the SSE transition, inclusion list, change to issuance. Everybody remember that debate? Could come back.

History expiry, EPBS, and accounts traction, right? Like with the new transaction type, maybe there'll be some learnings from that, from Pectra, that inform next steps. So lots of other EIPs that could be included. The scoping discussion for Fusaka will be an interesting one to watch. So in the audience, I hope this just goes to show, please be engaged in Ethereum governance.

I don't foresee, you know, very many upgrades left in Ethereum's future. So every upgrade counts and there's a lot of priorities on the list. And so it's worth it in the Ethereum ecosystem to make sure that your voice is heard and that decisions about where Ethereum protocol is heading is not made by like a few individuals or a few groups, but that the whole community and ecosystem gets involved. So thank you. I hope you learned something new about Ethereum and Pectra.

Thank you. Thank you. Thank you, Christine. We have a couple, we have a few minutes for Q&A. As you can see, you can sort of upvote them there.

So if you have one that you really want answered, please upvote right now. But I will let you take it away with when EOF. When EOF, I literally just said, the devs literally said that they are going to try and put it into Fusaka. Do I think that it's likely? Probably not.

Do I think that Fusaka is going to happen in 2025? Absolutely not. I think that the amount of time is taken to prepare Pectra, Fusaka will take a similar, if not longer time. Awesome. And then if we want to answer, I think we have time for one more.

Can you see them there? For us to increase blob target now in Pectra in case they get too expensive and so on. Yes, there definitely is an emergency path for increasing blob target. Oh, between now and Pektra activation. Hmm, no.

Because blob target is a hard-coded target and max in the execution layer and consensus layer. For that to change, for blob capacity to change, developers need to do a hard fork. So no, I do not think that there's any way for the blob capacity to increase between now and Pektra without a hard fork. Yeah. Actually, we are doing okay on time.

So we're going to keep cycling through these. Is the proposal to change the blob limit only or also the blob target? Okay. So that's a great question. Blob target, the most conservative increase is three to four, just changing the target, not changing's a great question.

Blob target, the most conservative increase is three to four, just changing the target, not changing the max at all. But that's not what layer two developers have asked for. There's this representative of the base team, a Coinbase's base team, and he's been vying for more aggressive increases. He's shown data to suggest that the increase wouldn't negatively impact the decentralization of Ethereum. So there's actually both.

There's a conservative proposal to just change the target, and then there's a more ambitious proposal to change both the max and the target to like, it's like eight and four, if not like six and 12. So there's varying gradients. There's actually a lot of different ways in which devs could increase the target. We'll see how conservative they choose to go for, but yeah. And I think I'm going to go first.

So you just urged people to be more involved in governance. We're going to jump to that question. How can the community get more involved in governance? Yes. Well, so ETH Research and ETH Magicians are two really great discussion forums for upvoting certain EIPs, showing your support for an EIP.

I would say those are two really good ones. Another one that is good, but probably a little bit harder for everyone to do, if you have a representative from your company that wants to really advocate for an EIP, the ACD calls are probably the most high signal place to do it. All you have to do is just leave a comment on the ACD call agenda on GitHub and say, like, this is an EIP that I'd like to speak about or present. And the moderator of the call is usually very agreeable to giving you that time. Don't take up too much time, though, like maybe like five minutes, for you to say your piece.

So use that chip sparingly, but that is probably one of the most...