# What’s Going Into the Pectra Upgrade? by Christine Kim | Devcon SEA

- Speakers: [Christine Kim](https://streameth.org/speakers/christine-kim)
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-09
- Duration: 25:16
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-ufIDBCgdGwY
- YouTube: https://www.youtube.com/watch?v=ufIDBCgdGwY

## Description

A talk explaining the core EIPs going into the Pectra upgrade and the core EIPs still TBD for inclusion in Pectra. The talk will also touch on Pectra timing and fork scoping for the next hard fork after Pectra. Finally, the talk will share insights about the governance process of Ethereum in light of Pectra and takeaways about the priorities of Ethereum protocol developers.

Speaker(s): Christine Kim
Skill level: Beginner
Track: Core Protocol
Keywords: fork, hard

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] [Music] on what is going into the Petra upgrade we're going to talk about all the eops that are going to the Petra upgrade quick disclaimer before I start everything I'm about to say is all informational uh for informational per 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 main T so I'm just going to get that out of the way um so we can get into the technical stuff um this is a very tentative timeline analysis and everyone's taking pictures already um when people ask me when is Petra gon to happen I say it's too early to tell because it's true te Petra is still in very early stages of its development specifications are changing there's the scope of pectra even has not really truly been finalized quite yet as we'll talk about um but through this process one of the things that you can learn is how upgrades get developed how upgrades get tested um and eventually make it onto mainnet so initially what happens is developers decide on a couple eips to include in an upgrade and then they Implement those eips onto private developer focused test Nets called Dev Nets and developers have already launched a couple of Dev Nets already for pectra um so these eaps 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 uh iterate they iterate on these eips uh by launching new Dev Nets devet 4 was launched um 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 pectra test net um this month it's called me Kong so you can go and interact with some of the eips that are going to be in pectra early on um it's based on devet 4 specifications um but please note that those specifications are changing there is a list of changes specifications changes to the eips that developers already want to uh include into pectra devet 5 so there's things like uh BLS um pre-compile repricing uh a new EIP that hasn't been implemented into devet 4 but uh developers are aiming to implement it in for devet 5 or a future upgrade so Petra 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 Petra upgrade in its progress to mainnet is for the scope to be finalized for all of the eips going into Petra um to be decided on 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 uh 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 um dynamically through the consensus layer rather rather than having those par parameters hard-coded in the execution layer and the consensus layer um so the addition of that mechanism into pectra suggests that developers are doing all the heavy lifting of trying to um Implement a change to blob capacity increase or a change to the blob capacity in pectra um but developers have not formally um decided or formally included um that increase like right now it's a target of three and a Max of six um they're not sure if it's going to be an increase of four or five or six um so ideally hopefully developers will be able to uh finalize that early next year um and I think as the specifications for the other pectra eips become hardened more uh finalized it puts pressure on developers to kind of activate them on mainnet and in order to do that you have to ensure that the scope of the upgrade is fully complete so um you know strong strong strong I guess like thinking or or reasoning that the uh fusaka not fusaka that the pectra scope will be uh finalized by early next year um and then once it is finalized you start testing uh whatever new eips that you've implemented the full scope of the Petra upgrade you test that um and battle test it on a couple more Dev Nets um I Envision say you know until maybe devet 6 or S um and then once the Petra specifications are frozen they are ready to go all the edge cases uh that developers can find on dev Nets have been found they will then release the Petra specifications uh release the Petra upgrade onto public ethereum test Nets there are two right now sooa and heski heski um Gorly is deprecated I believe um and historically developers have budgeted about two weeks between um public test net upgrades um in kind of rare occasions developers kind of shrunk that timeline down to even just one week between um test Nets but because of the size of pectra um I imagine that developers will want to take the full time to um see how the Petra upgrade fares on public test net environments um so I am budgeting roughly about a month for the sepolia and the heski heski I don't even know how you would say it right but heski thank you sir um yeah so that 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 main net activation um 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 maina will realistically happen next April 2025 um again this is very tentative um because a lot can change between now and um April development uh happens on a week toe basis developers are are on these ACD calls talking about um this bug that they didn't expect in this EIP or this new EIP that they do want to add into Petra now um so a lot of things can change this timeline um but looking into my crystal ball there you have it my timeline um let's move on to what is the meat you know the bread and butter of this talk which is what is going into Petra upgrade there are 10 eips that are going into Petra and four of them are focused on the execution layer oh my gosh the print is so small there um EIP 2537 it is a uh new pre-compile yay new pre-compile into the evm um BLS 12381 curve operation this is a new cryptographic signature scheme um that uh 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 dap developers were like we really want this because it would be um it would give daps um certain daps that are relying on zero knowledge cryptography um stronger stronger privacy guarantees um potentially increased security and scalability I believe BLS signatures that that signature scheme or that aggregation is also the signature aggregation that happens on the consensus layer for validator um attestations um it this CIP is a long time coming and so I think one of the concerns around the CIP is are there still apps that are waiting for the BLS precompile and will are they going to use it uh when that precompile goes live um so kind of an open question but if you're in this audience and um didn't know that the BLS pre-compile is finally coming it's coming um and maybe you know you're you have an app that hasn't already moved on from this vision and can still utilize this pre-compile in some pretty cool ways um so it's going into pectra uh EIP 2935 serve historical blasters from State um this one introduces is a change to the execution layer such that proofs of historical blocks can be generated from the state um this does have some near-term benefits so um it has some benefits for light cin syncing has um some benefits for smart contracts that may want to utilize um data about the state of a prior block um directly through the evm you can't actually do that right now um but those near-term benefits is not the reason that this EIP was included into pectra um because clearly those benefits are a little bit iffy um not like super important I guess but the main reason why that was included into Petra is because it's a prerequisite for veral and veral is uh this major overhaul to ethereum's uh the structure for uh State data on ethereum that developers had thought that transition was going to happen right after Petra so they're like oh you know faka this is when veral is going to happen oh well we need this EAP if we're going to do that veral transition um but turns out as we're going to talk later in this uh presentation verl is not going to go into um fusaka or at least that's not what developers are expecting right now um they've punted it out to another upgrade but it's still there developers did implement it um and it'll have some near-term benefits but the primary reason for it is um as a prerequisite to to veral um which you know could happen down the road um and if it does you know this this stepping stone has already been checked off the list EIP 7685 uh 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 um so in pectra there's a couple of 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 um the execution layer smart contracts on the execution layer will be able to trigger like validator withdrawals consolidations deposits um and rather than implementing these new um messages these new communication channels all in a separate kind of unique faction fashion uh the implementation of these generalized these execution layer triggerable requests um 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 um 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 G developer um like client he was like I think this would be a good EIP to add once developers started implementing those other e are like oh actually this is something that would be pretty useful um so that's why EIP 7685 is in there um and EIP to support the other eips uh e 772 this one's kind of I guess an exciting one um 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 um to have greater flexibility and enable features like what some that I think many people in the audience have been waiting for for a while um to enable EAS 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 um so it's kind of like a baby step to seeing how um this will improve the user experience um it is cool that um you know some kind of temporary functionality will um that you'll be able to create some kind of temporary new um flexibility into eoas um but really it's an early step um to see what the real road map to True native account abstraction could look like on ethereum um this had quite a bit of debate um in terms of how developers should take that first step um a lot of controversy of this one getting in and its design but it's in there and I'm pretty sure um of all the eips that developers want you to interact with and kind of test on the meong test net this is probably high up on the list um you know trying out this new transaction type so if you're on meong um you know thow developers a bone try it out there are six others these ones are consensus layer eips and 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 um EIP 7742 uncouple blob count between the consensus layer and the execution layer this one is the most recent EIP to be included into Petra um developers like I said um was considering should we include an increase to the blob capacity um and if we're going to do that currently the blob capacity is hardcoded into the execution layer and the consensus layer and the hard coding of these constants are all kind of different in all the clients um and so updating that hard coding is not as easy as um some may think um so creating a mechanism to kind of be able to change the blog capacity and have it dynamically set by the consensus layer um will ensure that in the future developers can easily change the blob capacity of ethereum if they want to and and um 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 um so yeah but it's like heavy work upfront right because the mechanism doesn't exist right now once the mechanism exists yes it'll be easy to use that mechanism and update the blob capacity but right now that mechanism doesn't exist so it takes quite a bit of work um which is why when developers were like look if we're really serious about including an increase the blob capacity in pectra we should really get started on this mechanism them sooner rather than later and so developers were like actually yes other developers on the call and the ACD calls I'm talking about they're like you what that's probably a good idea so that's why it was included but the last little lineup here TBD that's the blob capacity increase developers have not decided on what specifically that increase is going to be quite yet um let's dive deeper into some of these other ones EIP 6110 Spide to validator deposits on chain um Vall you know he was like woohoo you know then the mainstage talk like the merge happened um the merge happen and ethereum is more mature as a proof of stake blockchain there are certain security assumptions that can be relaxed now um and one of those security assumptions is an additional round of voting um 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 um this EIP removes that additional round of voting on the consensus layer side um ensures all the deposit validation happens on the execution layer um this has some uh benefits for validator ux it will shrink the time um between when you deposit your 32 eth and when you see the validator actually be activated on the beacon chain um EIP 70002 uh execution layer triggerable withdrawals this is very good for sticking pools um right now validators if you want to fully withdraw a validator the node operator that controls that operates that validator needs to um withdraw they need to uh use their withdrawal key to fully exit the validator um but through the CIP smart contracts will be able to initiate those full withdrawals so it's kind of a a trust assumption that you can now remove from staking pools um the likes of say like Lio rocket pool other smart contract based staking pools you can um those smart contracts can now trigger full withdrawals of validators if they wish um so a very nice nice feature for trustless and um improving the yes this I don't know like resiliency yes resiliency of uh smart staking pool smart contract based staking pools EAP 7251 increasing the maximum effect of balance I have written so many reports on the problem of ethereum's growing validator set size this really is an issue I guess we know when developers were thinking about the beacon chain um 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 um 1.5 million validators I think we're at like 1.2 or 1.3 somebody can check me on that um 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 um really is too much so it's um straining nodes um and you know left unchecked it would be a major problem for the health of ethereum so uh EIP 7251 is designed to encourage validators to consolidate their eth um and have a maximum effective balance higher than 32 eth and reduce the number of active validator on ethereum that is the goal of EIP 7251 let's see how quickly it is adopted once preure 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 uh EAP 7549 um move committee index outside attestation kind of like a restructuring refactoring of the way that attestations are um aggregated uh to make blocks or to reduce the networking load of ethereum again see there's clearly networking pains um and save node bandwidth um and kind of quick note about the CIP developers when they were including an incture I was like oh this is a this is a great change clearly has wonderful benefits an easy one to to go ahead with um in practice though um 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 um okay so in like the Outlook if you know I Blaze through that really fast don't worry in summary ra is a mixed bag of updates it's going to do three things it's going to fix critical shortcomings of ethereums as a proof of stake blockchain think about Max evb right like that's a critical fix that needs to happen because the validator set size can continue to grow unchecked um improve the user experience right we're talking about like the new transaction type make is more flexible some improvements for uh more trustless designs for sticking pools Etc some minor ux improvements there and number three uh ethereum's data availability capacity increasing that that hasn't been formally included into Petra but again seems likely moving on um okay here are all the eips that were removed from pectra this is kind of like a firsttime thing for um an upgrade to have so many eips removed from for from it um the first one is pias honestly there was going to be a much bigger increase to data availability capacity um in Petra initially when Petra was being scoped out pias is going to um allow developers to increase the blob Target of ethereum not from like 3 to four to like four to five but like by multiples more without um impacting greatly the um bandwidth consumption and the uh computational requirements of running in ethereum node but it's still in research and development phase um it's still being developed and these other 11 code changes as a bundle are called eoff it's this major update to the ethereum evm and both of these eips all these eips were really initially included in pectra but they were being tested on separate devet so you had the pectra eips that were moving along progressing um starting to solidify um starting to become more aspects of it were starting to become more or less finalized but pias and eof um there were developers thought that it would require a lot more time to get them really ready for mayet Activation and developers did not want to delay the activation of the Petra eips from getting onto Main net which is why one of the reasons was they wanted to get Petra out the Petra eips out sooner so they said pias and eof um clearly needs more time to be worked on we'll pump that to another upgrade and not hold back these other pector eips from mainnet another reason is this is a lot of eips in addition to the other 10 that I talked about um so lots of risk right um with the interdependencies of this code um trying to implement it all at once this is a lot of of work and time for the testing team and the client teams to be able to ensure there aren't any bugs um so lots of reasons for to I I would say actually main reasons for why these eips were removed from Petra and now they are moved to fusaka so again I have verl up there because verl was initially slated for fusaka but then now it's not going to because developers have given a soft confirmation that eof and pias are going to be into in faka but again obviously there's um changes happen like in the moment developers should be able to reassess priorities and uh make decisions accordingly um so it's like it's unlikely but there's a non-zero chance Anything Could Happen um verl so verl is not in fusaka for now and eof in pias for now is in P in um 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 um and give their full attention to fusaka after Petra um these are some of the other ones that were considered for pectra um but never made it in um 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 S transition inclusion list um change to issuance everybody remember that debate um could come back history expiry epbs um and accounts direction right like with the new transaction type maybe there'll be some learnings from that from pectra that inform next steps so lots of of other eips that could be um 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 um 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 um 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 um but that the whole community and ecosystem gets involved so thank you I hope you learned something new about ethereum and Petra thank you thank you thank you Christine we have a couple we have a few minutes for a 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 prep par 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 um is there for us to increase Petra in case they get too expensive and start um yes there definitely is an emergency path for increasing blob Target oh between now and Petra activation hm no cuz blob Target is is a hardcoded 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 pectra um 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 um blob Target there the most conservative increase is three to four just changing the target not changing the max at all but that's not what uh layer 2 developers have asked for base um there's this representative of the base team a coin bases base team and he's been vying for more aggressive um increases he's shown data to suggest that uh the increase wouldn't impact the the decentral negatively impact the decentralization of ethereum so there's actually both uh 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 um so there's varying gradients there's actually a a lot of different ways in which uh devs could increase uh the target um we'll see how conservative they uh choose to go for but yeah and I think I'm going to go first so you just urge 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 up voting certain eips showing your support for an EIP um I would say those are two really good ones um another one that is good but probably a little bit harder for everyone to do um if you have a representative from from your company that wants to really uh 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 uh speak about or present um and the moderator of the call is usually very agreeable to uh giving you the time um don't take up too much time though like maybe like 5 minutes um for you to like say your peace so um you know use that chip sparingly but um that is probably one of the most like uh