Pectra Network Upgrade Meta Thread

[radek]

Thanks for the info - @axic Do you plan to push that further?

[charles-cooper]

NONREENTRANT opcodes EIP for reentrancy protection opcodes by charles-cooper · Pull Request #8543 · ethereum/EIPs · GitHub

[lettucer]

I will bring to attention my detailed reasons for why EIP-7547, Inclusion Lists, should be taken off consideration for Pectra and the roadmap. It at best provides a false sense of censorship resistance and at worst creates another MEV market that heavily favors centralization due to trust issues and creates opportunities for sabotage.

The only way to make the builder market less centralized is to kill the private order flow integration through (1) education and (2) maximally easy to use, actually decentralized frontends. Telegram bots, Uniswap X, Metamask all exist to extract value from you and your participation in them only strengthens their position to negotiate with builders and undercut validators. The other way is to add better anonymity support to the protocol so anonymous builders can exist, but anonymity has never been a priority for Ethereum.

Lettuce not rush an anti-feature that has extremely debatable assumptions of future ecosystem behaviour, a heavy dev footprint and a centralizing effect.

[wminshew]

I would like to +1 on 7212 – feels like the easiest / low hanging fruit to boost smart account adoption

[abcoathup]

Additional proposed EIPs for Pectra

Update EIP-7600: Update eip-7600.md by timbeiko · Pull Request #8846 · ethereum/EIPs · GitHub

Feedback

Reth

[Copied from Eth R&D Discord]

EIP-7623: Increase calldata cost
We think it makes sense to increase the calldata cost for actors using calldata as DA to nudge them to use blobs instead. The change is relatively small as well, so we think it makes sense to include this in Pectra.

EIP-7742: Uncouple blob count between CL and EL
It makes sense to have this configuration live in a single place, and allows us to increase blob count without changes to EL in the future. The change is small, although a bit larger than EIP-7623. We’re supportive of including this in Pectra.

RIP-7212: Precompile for secp256r1 Curve Support
We’re excited about adding this precompile. Reth already has a working implementation of the RIP, so we’d be supportive of including this in Pectra, but we are also sensitive to the fact that not all client teams may have this implemented, and are OK with not including it in Pectra if others feel it adds too much extra work.

In summary :

• EIP-7623 : Strongly supportive of inclusion in Pectra
• EIP-7742 : Strongly supportive of inclusion in Pectra
• RIP-7212 : Supportive of inclusion in Pectra, if time permits

EF JavaScript team

[Copied from ethereum/pm]

Some statement from the EF JavaScript team on the proposed EIP additions and EIP changes (not sure if we have someone joining the call today):

CL Request additions (so all under “Encoding changes”, requests root → flat hash, flat encoding (no RLP), signature validity checks):
We are not sure if we have considered all eventual side effects here (e.g. is a flat encoding flexible enough for future request types?), but generally think these changes make sense.

EIP-7623: Increase calldata cost
General support for the idea, no opinion formed if the specific EIP is the optimal way of doing that.

EIP-7742: Uncouple blob count between CL and EL
Supportive.

EIP-7762: Increase MIN_BASE_FEE_PER_BLOB_GAS
Undecided, no consensus.

RIP-7212 (secp256r1 Curve) + SSZ EIPs
For the Pectra HF we think we have reached the tipping point where the complexity of the fork starts to outweight the benefits of having “just one fork”, this can already be felt on “getting everyone togehter” on new testnet versions, having all EIPs properly tested (already for the testnets),…

We therefore do not support the addition of any mid-size-or-larger EIPs (RIP-7212 + SSZ EIPs in this category) to the Pectra HF, independent of the usefulness of the respective EIP. In case that there might be a non-Verkle focused HF after Pectra this next HF can then be a candidate to combine these kind of EIPs, judging by experience additional similarly sized EIPs will likely join “naturally” for this fork.

Nethermind

[Copied from ethereum/pm]

Nethermind’s View:

EIP-7623: Increase calldata cost
Strongly supportive for inclusion in Pectra.

EIP-7742: Uncouple blob count between CL and EL
Strongly supportive for inclusion in Pectra…

EIP-7762: Increase MIN_BASE_FEE_PER_BLOB_GAS
Not discussed internally.

RIP-7212 (secp256r1 Curve)
Supportive for inclusion in Pectra. We need to verify benchmarks for this precompile and assess gas pricing.

SSZ EIPs
Supportive, but not in Pectra fork.

CL Request additions
We think this change makes sense.

[abcoathup]

As the scope of Pectra is being discussed for proposed for inclusion EIPs, we should consider the impact of a potential pivot of Fusaka from Verkle.

This may change the priority of either proposed for inclusion EIPs or EIPs not yet included in devnets (e.g. EOF, PeerDAS) as they could be considered for Fusaka instead.

This could reduce the scope of Pectra and reduce the risk by making Pectra easier to test.

[timbeiko]

Thanks for flagging! This came up on today’s call, see the notes here.

[TimDaub]

What is the process to add Ronan’s proposal of finally adding a timestamp to the logs?

Proposal for adding blockTimestamp to logs object returned by eth_getLogs and related requests

Motivation Currently, most contract events that act on the notion of time do not add timestamp information as it is already available on the block where the event occurs. This saves them the extra gas cost of adding timestamps to the events. Unfortunately eth_getLogs do not provide the timestamp as part of the log objects returned. And so indexers that fetches these events using eth_getLogs, need to make one extra request for each different block to get the timestamps at which these events hap…

I have seen Ronan approach Peter already in Bogota in 2022 about this and Peter said that this was possible to be added. Now it’s 2025 and we still don’t have this.

Seriously what is the problem with adding this finally? My crawler looks like total spaghetti code and I have to do an extra call PER LOG to download a block header just to get the stupid timestamp of a log. There are a ton of other app devs that profit from this change. I’m starting to pay more to Alchemy than I pay for Claude 3.7 because of this. Can devs PLS do smth?

[TimDaub]

@moodysalem

As an Ethereum validator and user, I’d like to see Verkle trees and anything else that unblocks state expiry and stateless clients prioritized above all else.

As an “Ethereum user” how do Verkle trees have any meaningful impact on your consumption or user experience with Ethereum? Highly skeptical

[moodysalem]

@TimDaub

As an “Ethereum user” how do Verkle trees have any meaningful impact on your consumption or user experience with Ethereum? Highly skeptical

It brings us closer to running stateless clients to interact with applications. As a user, I would rather not give my account address and IP address to an RPC provider (e.g. Infura, Alchemy) for the privilege of making a token transfer.

[TimDaub]

@moodysalem

It brings us closer to running stateless clients to interact with applications.

No user cares sorry

@moodysalem

As a user, I would rather not give my account address and IP address to an RPC provider (e.g. Infura, Alchemy) for the privilege of making a token transfer.

I’m 99% sure you can already do this with idk a VPN or whatever

[moodysalem]

@TimDaub

No user cares sorry

I’m a user, Tim, and you asked.

Today I cannot use Tornado cash with any wallet because no RPC will service me, or if they do service me they will block VPNs and log too much information about my interaction (linking my IP to my wallet + whatever calls I made). The ability to easily run a client that talks directly to the p2p network is absolutely required for decentralization.

[TimDaub]

OK this is fair and IMO u should have said it above when you were arguing for this. I do agree that you should be able to interact with any contracts that you want.

That said, I’m still skeptical that we need to embark on a multi year roadmap for statelessness just for you to be able to privately send transactions to Ethereum. My concern would be scope creep here. There is truly no other way to achieve what you want? Why can’t there be a set of politically neutral VPN providers that allow you to do your token transfers anonymously?

[TimDaub]

That said @moodysalem, how many people actually do need to send transactions to TC without their IP tracked?

Sadly the Ethereum decisions makers have introduced blobs at such a timing that the fee accrual for this year is 10x less that of last year (source: Token Terminal). So while I do agree that the protocol has to serve morally right use cases etc., I think the protocol should at this stage critically prioritize changes that fix what has been broken or not finished…

I honestly don’t understand why e.g. we should ship statelessness. In what meaningful way does that e.g. double the month active addresses, which have been stagnating for years? As for blob storage, it seemed to have been the game theoretic ideal to lower fees that much. OK. But now the effort has to go into how the protocol keeps on capturing that value and other ways to fix this.
ETH is worth less now, mechanically, because you cannot extract that much money through holding and staking it anymore. And the future doesn’t look rosy here either. So your special privacy wishes can wait IMO

[CMG]

Could I please get a list of the EIPs that are confirmed to be included in the Pectra upgrade?

[CMG]

Anyone? Looking for this info urgently.

[timbeiko]

The Pectra EIPs are listed here: EIP-7600: Hardfork Meta - Pectra