Title: Pectra_Network_Upgrade_Meta_Thread
Category: Magicians

Author: timbeiko
Date: 2023-11-28T23:08:46.513Z

May 22 Update
From EIP-7600: Hardfork Meta - Pectra:

EIPs Included

EIP-2537: Precompile for BLS12-381 curve operations
EIP-2935: Save historical block hashes in state
EIP-3074: AUTH and AUTHCALL opcodes
EIP-6110: Supply validator deposits on chain
EIP-7002: Execution layer triggerable exits
EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
EIP-7549: Move committee index outside Attestation
EIP-7685: General purpose execution layer requests

EIPs Considered for Inclusion

EIP-7212: Precompile for secp256r1 Curve Support
EIP-7547: Inclusion lists
EIP-7623: Increase calldata cost
EOF EIPs listed as part of EIP-7692, namely:

EIP-663: SWAPN, DUPN and EXCHANGE instructions
EIP-3540: EOF - EVM Object Format v1
EIP-3670: EOF - Code Validation
EIP-4200: EOF - Static relative jumps
EIP-4750: EOF - Functions
EIP-5450: EOF - Stack Validation
EIP-6206: EOF - JUMPF and non-returning functions
EIP-7069: Revamped CALL instructions
EIP-7480: EOF - Data section access instructions
EIP-7620: EOF Contract Creation
EIP-7698: EOF - Creation transaction




Other Pectra Proposals

EIP-3068: Precompile for BN256 HashToCurve Algorithms
EIP-5806: Delegate transaction
EIP-5920: PAY opcode
EIP-6404: SSZ Transactions Root
EIP-6465: SSZ Withdrawals Root
EIP-6466: SSZ Receipts Root
EIP-6493: SSZ Transaction Signature Scheme
EIP-6913: SETCODE instruction
EIP-6914: Reuse validator indices
EIP-7702: Set EOA account code for one transaction
EIP-7212: Precompile for secp256r1 Curve Support
EIP-7377: Migration Transaction
EIP-7545: Verkle proof verification precompile
EIP-7553: Separated Payer Transaction
EIP-7557: Block-level Warming
EIP-7594: PeerDAS - Peer Data Availability Sampling
EIP-7609: Decrease TLOAD/TSTORE pricing for common cases
EIP-7623: Increase calldata cost
EIP-7664: Access-Key opcode
EIP-7667: Raise gas costs of hash functions
NONREENTRANT & REENTRANT opcodes


 April 10 Update 
Note: I accidentally removed EOF from the proposals list as part of my March 28 update. Fixed on April 5th. Also including EIP-7667 to the list which was recently proposed
From EIP-7600: Hardfork Meta - Pectra:

EIPs Included

EIP-2537: Precompile for BLS12-381 curve operations
EIP-6110: Supply validator deposits on chain
EIP-7002: Execution layer triggerable exits
EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
EIP-7549: Move committee index outside Attestation

EIPs Considered for Inclusion

EIP-7547: Inclusion lists


Other Pectra Proposals

EOF (megaspec, implementation matrix)
EIP-2935: Save historical block hashes in state
EIP-3068: Precompile for BN256 HashToCurve Algorithms
EIP-3074: AUTH and AUTHCALL opcodes
EIP-5806: Delegate transaction
EIP-5920: PAY opcode
EIP-6404: SSZ Transactions Root
EIP-6465: SSZ Withdrawals Root
EIP-6466: SSZ Receipts Root
EIP-6493: SSZ Transaction Signature Scheme
EIP-6913: SETCODE instruction
EIP-6914: Reuse validator indices
EIP-7212: Precompile for secp256r1 Curve Support
EIP-7377: Migration Transaction
EIP-7545: Verkle proof verification precompile
EIP-7553: Separated Payer Transaction
EIP-7557: Block-level Warming
EIP-7594: PeerDAS - Peer Data Availability Sampling
EIP-7609: Decrease TLOAD/TSTORE pricing for common cases
EIP-7623: Increase calldata cost
EIP-7664: Access-Key opcode
 EIP-7667: Raise gas costs of hash functions

Post-Pectra Proposals
Execution Layer: Osaka
From EIP-7607: Hardfork Meta - Osaka:

Considered for Inclusion

EIP-4762: Statelessness gas cost changes
EIP-6800: Ethereum state using a unified verkle tree
EIP-6873: Preimage retention
EIP-7545: Verkle proof verification precompile


Consensus Layer: F-Star
Likely focus on EIP-7594: PeerDAS - Peer Data Availability Sampling



 February 5, 2024 Update 

Prague/Electra Meta EIP PR

EIPs 6110, 7002 and 7549 Included
EIP-2537 CFI’d


Verkle Tries included in post-Prague EL fork, Osaka
EIP-4444 work to continue in parallel to network upgrades
CL proposal tracker
Other EL proposals, in order of appearance here:

EVM Object Format (EOF)
EIP-3074: AUTH and AUTHCALL opcodes
EIP-3068: Precompile for BN256 HashToCurve Algorithms
EIP-6913: SETCODE instruction
Increase codesize limit to 2**16
EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
EIP-7377: Migration Transaction
EIP-7547: Inclusion Lists
EIP-7212: Precompile for secp256r1 Curve Support
EIP-5920: PAY opcode
EIP-7553: Separated Payer Transaction
EIP-5806: Delegate transaction
EIP-7609: Decrease TLOAD/TSTORE pricing for common cases
EIP-6404: SSZ Transactions Root
EIP-6465: SSZ Withdrawals Root
EIP-6466: SSZ Receipts Root
EIP-7557: Block-level Warming






 January 15, 2024 Update 
Jan 15, 2024 Update
Proposals so far, in order of appearance, highlighting if they are for the [EL], [CL] or [EL+CL]:

[EL] EIP-2537: Precompile for BLS12-381 curve operations
[EL] EVM Object Format (EOF)
[EL+CL] EIP-7002: Execution layer triggerable exits
[EL] Verkle Trees
[CL] EIP-7549: Move committee index outside Attestation
[EL] EIP-3074: AUTH and AUTHCALL opcodes
[EL]  EIP-3068: Precompile for BN256 HashToCurve Algorithms
[EL+CL] EIP-6110: Supply validator deposits on chain
[EL] EIP-6913: SETCODE instruction
[EL] Increase codesize limit to 2**16
[CL]  EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
[EL] EIP-7377: Migration Transaction
[EL+CL] EIP-4444: Bound Historical Data in Execution Clients
[EL+CL] EIP-7547: Inclusion Lists
[EL] EIP-7212: Precompile for secp256r1 Curve Support
[EL] EIP-5920: PAY opcode
[EL] EIP-7553: Separated Payer Transaction
[CL] EIP-7594: PeerDAS

Additionally, here are extra proposals from the CL Github issue:

EIP-6404: SSZ Transactions Root
EIP-6465: SSZ Withdrawals Root
EIP-6466: SSZ Receipts Root
EIP-6914: Reuse validator indices




 December 19, 2023 Update 
Dec 19th Update
Given the activity here, I’ll compile the proposals to date, in order of appearance, highlighting if they are for the [EL], [CL] or [EL+CL]:

[EL] EIP-2537: Precompile for BLS12-381 curve operations
[EL] EVM Object Format (EOF)
[EL+CL] EIP-7002: Execution layer triggerable exits
[EL] Verkle Trees
[CL] EIP-7549: Move committee index outside Attestation
[EL] EIP-3074: AUTH and AUTHCALL opcodes
[EL]  EIP-3068: Precompile for BN256 HashToCurve Algorithms
[EL+CL] EIP-6110: Supply validator deposits on chain
[EL] EIP-6913: SETCODE instruction
[EL] Increase codesize limit to 2**16
[CL]  EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
[EL] EIP-7377: Migration Transaction
[EL+CL] EIP-4444: Bound Historical Data in Execution Clients

Additionally, here are extra proposals from the CL Github issue:

EIP-6404: SSZ Transactions Root
EIP-6465: SSZ Withdrawals Root
EIP-6466: SSZ Receipts Root
EIP-6914: Reuse validator indices




 Orignal Post  
With Dencun wrapping up, the time has come to start thinking about the Prague/Electra upgrade. Similarly to Cancun, I propose using this thread to discuss the overall process and scope of the upgrade.
EIP champions can use the prague-candidate tag to signal their desire for inclusion in the upgrade. Note that the consensus layer teams already have a Github issue to track proposals.

As for larger process tweaks, my #1 suggestion is to  bring back Meta EIPs.
There currently is no good place to track the full scope of a network upgrade prior to it being deployed and announced in a blog post.
For Dencun, we have EL EIPs in a hard to find markdown file and CL EIPs as part of the Beacon Chain spec.
This isn’t great, as both of these are somewhat hard to find, each of them uses a separate “format” and it results in duplication. With ERC and EIPs now separate, I suggest (going back to) using Meta EIPs to track EIPs included in network upgrades.
For coupled upgrades, the EL + CL could share a single Meta EIP, and for de-coupled upgrades, they could each have their own. If an upgrade goes from coupled to de-coupled or vice-versa, we can simply create a new Meta EIP which superceeds the previous one.

Lastly, as a “stretch goal”, we should agree on what to do with “Considered for Inclusion”. This “proto-status” was created to provide more legibility to EIP champions about which EIPs may be included in an upgrade. That said, it can be argued the lack of commitment associated with CFI causes more confusion than it removes. Additionally, CFI is only used on the execution layer.
If it isn’t useful, we should consider modifying or removing it, or potentially harmonizing its definition and usage across both the EL & CL processes.

Author: ralexstokes
Date: 2023-11-28T23:46:20.594Z

I’ll go ahead and kick things off with EIP-2537
There may be some minor change to the precompiles and gas schedule but this will all be together in time for serious inclusion discussions for Prague/Electra.
AFAIK previous concerns around this EIP have been resolved (e.g. hardened BLS12-381 implementations in production, esp. given that this code is used in EIP-4844 in Cancun/Deneb) and there is plenty of demand from both rollups and cryptography use cases.
One of my top priorities for this hard fork will be championing for inclusion of BLS12-381 precompiles and it seems like prime time

Author: gballet
Date: 2023-11-29T05:34:01.170Z

are we talking about the next major HF or the “small” one between Dencun and the former? Because if it’s the next major HF, the complexity of verkle trees won’t leave much room for anything else.
And if it’s a smaller one, I don’t think we should call it Prague, in the hope that we can pull smaller hardforks faster than we can have devcons. Note that we can no longer add devconnect names, as Instanbul already exists as a fork.

Author: Tudmotu
Date: 2023-11-29T12:49:21.123Z

Not sure if it’s the right place to ask, but is there an update on EOF inclusion? Is it planned for Prague?

Author: shemnon
Date: 2023-11-29T16:11:53.352Z

gballet:

Note that we can no longer add devconnect names, as Instanbul already exists as a fork.


We’ve already used three names for Istanbul: Byzantium, Constantinople, and Istanbul.  There’s a list on wikipedia with more options.
If we run ahead of devcon/devconnect names we could just use more names for istanbul

Author: timbeiko
Date: 2023-11-29T16:30:18.224Z

gballet:

are we talking about the next major HF or the “small” one between Dencun and the former?


I’m personally not really a believer in “small” forks. Historically, the only times we’ve had truly small or quick forks were either emergencies, or simple difficulty bomb pushback. For example, Shanghai was a “small” fork relative to The Merge, and it still shipped 6-7 months after it.
If we are considering any non-trivial EIPs, I’d call this Prague for simplicity. Whether it’s a 6-9 month fork like Shanghai or a 9+ month one like Cancun can only be very roughly predicted based on what EIPs we decide to include.
That said, I agree that we should make a call about whether we include Verkle or not ASAP, as it will dictate how much extra capacity there is for other EIPs.

Author: gballet
Date: 2023-11-29T18:54:42.806Z

also not a believer in “small forks”, but I’ve heard a mention of a fork with only minimal EIPs.

Author: timbeiko
Date: 2023-11-29T18:56:28.440Z

Right, assuming we didn’t do Verkle, we could choose to only do a set of smaller EIPs, but I just want to make sure we don’t do that thinking “it will be done in 3 months” when it’s likely to take 2x+ longer

Author: gcolvin
Date: 2023-11-29T22:36:34.104Z

gballet:

if it’s the next major HF, the complexity of verkle trees won’t leave much room for anything else


At this point the EOF proposals represent some seven years of research and development.  They are solid.  They are needed.  They are really not that difficult to implement.  And the researchers and developers are burning out.  It’s time to get them into an upgrade.

Author: Wander
Date: 2023-11-30T05:19:24.355Z

I think EIP 7002 (EL-induced exits) deserves a mention. The staking community badly needs a way to trigger exits via smart contracts to finally and fully close the loop on trustless staking protocols.
Some interesting ideas for potentially improving it were tossed around at DevConnect this year, but even if it’s included as-is, Ethereum would be significantly safer.

Author: Giulio2002
Date: 2023-12-01T12:43:25.688Z

I think Verkle trees alongside with very few small EIPs (Verkle tree is a big update) such as EIP-2537 is desirable, in alternative we can focus on EOF and many small EIPs

Author: prebuffo
Date: 2023-12-01T13:14:21.847Z

I would divide the discussion into two parts, namely which large EIP (or series of EIPs) to include between Verkle Tree and EOF, and which other ‘small’ EIP to include.
Between Verkle Tree and EOF, a check should be made on the maturity of the project and the opinion of the Core Teams on it.

Author: dgusakov
Date: 2023-12-01T13:14:55.656Z

I believe EIP-7002 is one of the best candidates for inclusion in the next hardfork.
My team and I are working on designing and developing Lido Community Staking Module (CSM). This module is aimed to offer permissionless entry to the Lido on Ethereum validator set. EIP-7002 greatly influences the risk profile of CSM and any other permissionless staking solution. With EIP-7002 in place, CSM will become more attractive for Lido DAO to increase its staking share. Hence, more independent operators will be able to join Ethereum validation.

Author: TheDZhon
Date: 2023-12-01T15:01:37.943Z

I also feel that including EIP-7002: Execution Layer Triggerable Exits would be a good choice for the network, being crucial not only for liquid staking protocols, and pretty sure not only for Lido.
What I am afraid of is after enabling EIP-7044: Perpetually valid signed voluntary exits in Dencun, there will be a long-term tail risk of storing and distributing the exit messages in staking protocols involving increased trust assumptions.
If EIP-7002 wasn’t included, it’s predictable that protocols trying to build a permissionless validator set (e.g., requiring bonds) would try to rely on joining the set with a pre-signed exit message intent. The message then should be stored and split in a distributed way. However, as the messages will have an infinite expiration time, it would pose a risk of falsely ‘losing’ the pieces or, in contrast, firing up exits spuriously, potentially leading to turbulence or fund losses.
In contrast, if EIP-7002 is implemented, the trust level built into the staking protocols would be reduced, not expanded.
Finally, EL triggerable exits are akin to Account Abstraction direction: getting rid of UX and trust issues with a smart contract that’s where Ethereum is great.
Thank you for raising this on the topic.

Author: abcoathup
Date: 2023-12-01T20:31:13.726Z

[EDIT]: Not a commentary on the merits of EIP7002.



 dgusakov:

Lido DAO to increase its staking share


Lido is currently at 32.28%.
We shouldn’t want any entity to have a share of stake above 33.3% threshold.



HackMD



The Risks of LSD - HackMD
# The Risks of LSD  ### Liquid Staking Derivatives cannot safely exceed consensus thresholds  Liquid

Author: Wander
Date: 2023-12-01T20:36:39.794Z

Strongly agree with this, but I think the adoption of 7002 is independent of this issue and simply provides a safety benefit for all LSTs. If the recent discussion on adjusting the mechanics pans out, it could even benefit smaller LSTs more heavily.

Author: dgusakov
Date: 2023-12-02T03:35:46.381Z

I was meaning share of CSM within Lido and overall Lido share.

Author: dapplion
Date: 2023-12-05T12:27:30.664Z

I want to propose EIP-7549: Move committee index outside Attestation
It’s a very simple consensus-only change that reduces the cost of verifying casper FFG by a factor of 64x. As such, it accelerates the viability of ZK trustless bridges on Ethereum.

Author: smartprogrammer
Date: 2023-12-05T17:25:19.318Z

I would like to re-propose EIP-3074: AUTH and AUTHCALL opcodes

Author: poojaranjan
Date: 2023-12-06T14:58:04.716Z

timbeiko:

Lastly, as a “stretch goal”, we should agree on what to do with “Considered for Inclusion” . This “proto-status” was created to provide more legibility to EIP champions about which EIPs may be included in an upgrade. That said, it can be argued the lack of commitment associated with CFI causes more confusion than it removes. Additionally, CFI is only used on the execution layer.
If it isn’t useful, we should consider modifying or removing it, or potentially harmonizing its definition and usage across both the EL & CL processes.


Earlier, Meta EIP used to list proposals considered for an upgrade. “CFI” was created to fill the gap and provide visibility on the list of proposals under consideration for an upgrade where devs are preparing for multiple upgrades in parallel.
With “Upgrade Meta Thread” and the “Meta EIP” for an upgrade getting back in, I do have places to look for EIPs list rather than depending on “CFIs”.
To keep the EIP status harmonized across layers, type & categories. I’d support removing “CFI”.
For Core EIPs we can have standard statuses as explained in EIP-1 with a high-level understanding of when to change the status as below:
Draft = 1st PR
Review = Whenever ready for clients’ review/implementation/devnet
Last Call = When moved to 1st Public Testnet
Final = When deployed on the Mainnet

Author: CluEleSsUK
Date: 2023-12-06T16:46:53.273Z

EIP-3068: Precompile for BN256 HashToCurve Algorithms would be amazing (and its counterpart for EIP-2537: Precompile for BLS12-381 curve operations, which @ralexstokes already brought up!).
BN254 and a lot of threshold work is really hamstrung without hash_to_curve.

Author: mkalinin
Date: 2023-12-07T08:34:04.812Z

I am proposing EIP-6110: Supply validator deposits on chain for Prague/Electra
This EIP deprecates Eth1 bridge — a legacy way to deliver validator deposits to the beacon chain. Upsides of the proposed deposit delivery mechanism:

JSON-RPC is no longer used to query deposit contract logs

no constant load on an EL client induced by CL today
no pain for node operators, EL and CL client devs in resolving issues with deposit log querying


Eth1Data voting is no longer the case

no design flaw undermining security of the core protocol (fixes consensus-specs#1632)
no potential bugs in Eth1 bridge implementations in CL clients leading to liveness issues on the mainnet
no need for entire history of deposits and deposit contract snapshots to bootstrap CL


Instant deposit processing, no need to wait for ~12 hours to see your deposit is processed by CL

Author: wjmelements
Date: 2023-12-07T20:07:18.243Z

AUTHCALL for empowered EOAs
SETCODE for account upgrades post-SELFDESTRUCT
Increase codesize limit to 2**16

Author: langers
Date: 2023-12-12T05:12:11.078Z

At Rocket Pool, we would like to +1: EIP-7002 - Execution Layer Triggerable Exit
The combination of EIP-4788 and EIP-7002, gives a fantastic design surface for decentralised / trustless staking protocols, providing the foundation for much needed competition in the space.

Author: mikeneuder
Date: 2023-12-12T19:48:41.359Z

I’d like to include EIP-7251 for consideration!
See related documents here: eip7251 related work · GitHub
We are working soliciting feedback for the final set of features from key stakeholders

Author: pintail
Date: 2023-12-12T23:08:21.973Z

This lays foundations for a sustainable validator set size for the network as it is today but also is a prerequisite for single slot finally, ePBS and MEV-burn. The current 32 ETH MaxEB is a relic of the old eth2 roadmap and is a barrier in the way of many other proposals.

Author: paulhauner
Date: 2023-12-15T05:46:02.453Z

Also +1 for EIP-7002: Execution layer triggerable exits for the benefit of non-custodial staking services.
The ability for users to exit of their own accord, without action from their staking provider, is critical for staking services to remain non-custodial in the eyes of regulators. It’s possible with VoluntaryExit messages, but it’s very awkward and requires exchange of a “secret message” between the user and the staking service. With EIP-7002 the entire interaction can take place publicly on-chain.
EIP-7002 would put the last necessary piece in place for simple and elegant non-custodial staking offerings. While complex liquid staking offerings are clearly appealing, I think there’s also space for ultra-simple, non-liquid, delegated staking directly between node operators and ETH holders. They could offer lower fees due to lower overheads and be attractive to whales looking for a “fixed-term deposit” rather than high liquidity.

Author: garyschulte
Date: 2023-12-18T23:13:59.293Z

EIP-7377 would go a long way to getting existing users/EOAs into smart contract wallets.  I think it is a cost effective and elegant way to enable this transition.
EOA migration as presented is fairly easy to reason about and low complexity to implement.  Given the cost/benefit it should be CFI.

Author: non-fungible-nelson
Date: 2023-12-19T17:17:45.593Z

I would like to propose EIP-4444, dependent upon shipping EIP-6110.
We are already seeing discussions/disagreements around how clients today are bounding historical state on disk and in sync. Codifying a behavior in an upgrade will help solo-stakers and node operators at a time when we need more client/hardware diversity, not less. Portal Network has also signaled their readiness to serve historical state data. The cherry on top is that its implementation within clients is optional!
If we can tie 6110 together with 4444, some of the EL/CL complexity goes away. 4444 would allow clients to remove code tied to historical block processing. With EOF, there may be more simplicity in overall maintenance of EVM client code. This change also plays nicely with the Verkle transition as it could allow for more room on disk at the time of the transition, but may need to be shipped in advance…

Author: matt
Date: 2023-12-20T16:08:00.417Z

I’d like to propose EIP-7547: Inclusion Lists as a potential Pectra candidate.
This is a screenshot from mevboost.pics showing what percentage of all blocks come from which individual builder:
Screenshot 2023-12-20 at 09.04.18371×324 25 KB
As you can see, the top 5 builders control about 80% of all blocks. 4 out of 5 of them are already censoring txs. I think it’s important to consider addressing this situation in-protocol with something along the lines of Inclusion Lists.

Author: mikeneuder
Date: 2023-12-20T18:26:50.125Z

I’d like to +1 EIP-7547: EIP-7547: Inclusion lists && https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7547.md.
Especially with the advent of builder and relay censorship, getting a forced inclusion mechanism enshrined feels super important! See Toni’s excellent https://censorship.pics.

Author: non-fungible-nelson
Date: 2023-12-20T20:01:04.740Z

I would also like to propose EIP-7212: Precompile for secp256r1 Curve Support
With the movement towards SC wallets and an ERC-4337 enabled future for users on-chain, this precompile rounds out the toolset for creating amazing wallet experiences and enabling embedded wallets. Native integration with Passkeys, iOS and Android secure enclaves and WebAUTHN opens up great UX for users in a future moving away from passwords / private keys anyways.
We are already considering a ton of precomiples for this hard fork though.

Author: charles-cooper
Date: 2023-12-21T15:09:37.049Z

EIP-5920: PAY opcode, it was punted on for cancun because of potential complexity but otherwise was considered “good-to-have” in the EVM

Author: shemnon
Date: 2023-12-26T00:31:31.543Z

FYI the PAY opcode and 3074’s AUTH are both currently allocated to the same opcode.  PAY currently has the better claim - https://github.com/ethereum/execution-specs/blob/master/lists/evm/pending-opcodes.md

Author: tkstanczak
Date: 2024-01-04T02:46:08.400Z

Proposing a Separated Payer Transaction EIP (EIP-7553 Draft)


github.com/ethereum/EIPs








create Separated Payer Transaction EIP



          Commit by
          

            adietrichs
           - Add EIP: Separated Payer Transaction



master ← adietrichs:payer-sender-separation

Author: zerosnacks
Date: 2024-01-04T15:53:49.467Z

Hi William,
Regarding the proposed change to the codesize limit, is there already an EIP for that? Having developed workarounds to deal with contract size limitations I can underscore that even a bump to 2**15 but preferably 2**16 would have a huge positive impact for developers.
Thanks

Author: prebuffo
Date: 2024-01-04T18:02:00.741Z

I just read the summary of the last ACDC made on twitter by lightclient (excellent work by the way), and if it is true that focusing on the transition to Verkle Trees blocks everything else for at least 12 months and probably 24, then I propose to make at least 1 if not 2 intermediate forks both to add some much-needed features and above all to get EOF through first, which seems to me technically much simpler to implement.

Author: eawosika
Date: 2024-01-09T20:28:52.974Z

EIP-7002 is appearing in a lot of comments here, so it feels like a good opportunity to share a deep dive on EIP-7002 I published recently: EIP-7002: Unpacking Improvements to Staking UX Post-Merge. The article is an attempt to aggregate several perspectives on EIP-7002 I’ve come across (e.g., @TheDZhon’s “execution-layer exits are akin to account abstraction” comment inspired an entire section of the article) and provide a holistic overview of the advantages and potential drawbacks of implementing EIP-7002.
All feedback and comments are welcome.

Author: LukaszRozmej
Date: 2024-01-10T12:13:13.078Z

There is some community push for increasing gas limit. As core devs know this has major drawbacks in latency (network and processing) and storage. Current storage cost is mainly in Blocks and Receipts and not in State. So I propose to prioritise EIP-4444 if we want to consider increasing gas limit in the foreseeable future.

Author: eawosika
Date: 2024-01-12T21:24:13.358Z

I recently published an in-depth explainer on EIP-7251 for those interested in learning more about the proposal to increase MAX_EFFECTIVE_BALANCE from 32 ETH to 2048 ETH and implement in-protocol validator consolidation: EIP-7251: Implications of Increasing MaxEB for Validators
The article explains how EIP-7251 modifies aspects of the consensus protocol like validator activations, deposits, withdrawals, and slashing penalties to enable validator consolidation–while preserving the Beacon Chain’s existing security properties. It also addresses regarding increased slashing risk for large validators and (potential) regulatory issues arising from implementing EIP-7251’s auto-compounding rewards feature. All comments/feedback are welcome.

Author: mikeneuder
Date: 2024-01-15T18:08:43.387Z

thanks for writing this Emmanuel! it pulls everything together in a really comprehensive way!

Author: timbeiko
Date: 2024-01-16T19:27:55.608Z

Here are all the proposals so far across the EL + CL in visual form:
prague-electra.drawio1920×2901 236 KB

Author: ernestognw
Date: 2024-01-16T22:16:15.932Z

We at OpenZeppelin are also interested in EIP-7212 since we’re already considering to add a Solidity implementation

Author: gakonst
Date: 2024-01-17T18:46:36.682Z

Here’s the Reth team view on post-Cancun planning, keen to hear people’s thoughts.

Author: prebuffo
Date: 2024-01-20T09:05:02.529Z

Hallo, Paolo from Erigon, We would like to know if there is any opposition in principle to the implementation of EOF by other teams, we believe that EOF is fundamental but we would not like to waste time on a feature that will never be implemented due to the opposition of other development teams. It is not a question of when EOF will be implemented but whether it will ever be implemented.

Author: Amxx
Date: 2024-01-25T13:01:58.421Z

Following the discussion in the last Execution Layer Meeting (#179), I’d like to discuss EIP-5806. In particular, I’d be open to answerring any questions. I’d also like to have a better understanding of what are the next steps in the development of this EIP.

Author: charles-cooper
Date: 2024-02-01T14:36:21.282Z

i’d also like to add reduce transient pricing for common cases by charles-cooper · Pull Request #8158 · ethereum/EIPs · GitHub (draft, benchmarks underway) for consideration

Author: moodysalem
Date: 2024-02-01T15:07:13.903Z

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. I prefer a delay in the next hard fork over shipping other EIPs. PeerDAS is also very interesting, as long as it does not interfere with shipping Verkle trees. And increasing the max validator size is great for solo validators as well.
As an EVM developer, I am opposed to EOF. I am not convinced of the value in creating a new version of the EVM while still forever maintaining past versions. Even if it’s an order of magnitude more efficient,  unless there is a plan to disable, remove, or (impossibly?) migrate older code, my main concern is the developer overhead for working with multiple versions of the EVM as well as the increased risk of client bugs.
Upgradeability of EOF contracts could limit this to a small number of versions, but older versions will always exist and will also stop receiving improvements, and minor improvements in efficiency of EOF execution will not be sufficient to encourage a large scale migration.

Author: shemnon
Date: 2024-02-02T01:28:09.160Z

EOF is not a new version EVM.   It is a container format around the existing EVM model and a number opcodes to fix several issues related to technical debt: static jumps, code validation, subroutines, removing code introspection, and removing gas introspection.  The core model of the EVM remains the same, and Legacy EVM and EOF can freeley call each other with the exact same semantics.  Your traces will look mostly the same (new opcodes aside) and the same techniques you use to develop will be the same.  To most smart contract developers it will be nothing more than toggling a switch in solidity or vyper, and your code will also be a little smaller once you do.
The biggest immediate advantage that EOF unlocks it the ability to safely uncap or significantly raise the smart contract size limit (but the block gas limit will always be a mainnet cap).  Because of JUMPDEST analysis we have to limit the sizes or open the legacy EVM up to significant DOS attacks.  Code validation fixes this.
As for the legacy EVM, deprecating it is totally in my roadmap.  But first we need to get EOF out and used before we can ramp up discussion about deprecating new deployments and examining ways to migrate legacy EVM code, if such migrations are required.  This would start with closing off deployments of new legacy contracts, or possibly making them progressively more expensive.  I see this only ocuring at create transactions, factory contracts (like pools) would necessarily remain as-is.

Author: timbeiko
Date: 2024-02-05T22:44:34.587Z

Quick update:
On ACDE#180, EL teams agreed to move forward with Verkle Tries as the main feature of the Osaka upgrade.
Additionally, EL + CL teams have agreed to include EIPs 6110, 7002 and 7549 in the Prague/Electra upgrade (Meta EIP PR). EL teams had previously signalled desire to include EIP-2537 as well.
On ACDE#181, EL teams are expected to determine which other EIPs should be included in Prague/Electra.
In image form, here’s where we’re at:
prague-electra.drawio (1)1746×3126 464 KB

Author: eawosika
Date: 2024-03-13T20:11:08.224Z

Hi Ethereum magicians, I recently published an in-depth explainer on EIP-7251 for those interested in learning more about EIP-6110’s proposal to introduce on-chain validator deposits and deprecate the Eth1-Eth2 bridge in favor of a simple, secure, and more efficient system for delivering deposits to the Beacon Chain: EIP-6110: Fixing Beacon Chain Tech Debt
The article provides historical context for the Eth1-Eth2 bridge and Eth1Data polling mechanism (which underpin the Beacon Chain’s existing deposit processing mechanism) and explores the impact of maintaining both components on node operator UX and the Beacon Chain’s economic security (among other things). It also explores EIP-6110’s approach to reforming the validator deposit process and analyzes the advantages and potential drawbacks of replacing the existing deposit processing workflow with an in-protocol deposit processing mechanism.
All comments/feedback are welcome.

Author: Mr-Sanderz
Date: 2024-03-17T18:55:32.939Z

Assuming ~2 million validators is still best estimate for when finality delays/issues start popping up frequently enough, and we’re closing in on 1 million currently - within what timeline do you think something like 7251 is absolutely needed?  so if it’s not in Pectra, how big a deal would that be?  factoring in EIP-7514 which’ll buy some time now

Author: protolambda
Date: 2024-03-28T07:01:16.143Z

I hereby would like to propose EIP-7664 ( EIP-7664: Access-Key opcode ) for inclusion in Pectra.
It’s a very minimal new opcode, that serves as alternative to functionality that gets broken with EIP-3074: the ability for a contract to enforce data to be declared statically in a transaction.

Author: mratsim
Date: 2024-04-06T14:37:11.348Z

Reviewing and implementing EIP-2537 reminded me that it was not the only long forgotten but implemented BLS12-381 EIP.
There is also:

ERC-2333 - BLS12-381 Key Generation: ERC-2333: BLS12-381 Key Generation
ERC-2334 - BLS12-381 Deterministic Account Hierarchy: ERC-2334: BLS12-381 Deterministic Account Hierarchy
ERC-2335 - BLS12-381 Keystore: ERC-2335: BLS12-381 Keystore

Discussion thread: ERC-2333, ERC-2334, ERC-2335: BLS12-381 Key Generation, Deterministic Account Hierarchy, Keystore
Those are all in stagnant status, but in practice they are required to stake and are implemented by all consensus clients already for the past 4 years.
They probably deserve a mention in one Ethereum upgrade, if only to tell hardware providers that “no they aren’t stagnant, they really are THE standard”.

Author: eawosika
Date: 2024-04-08T14:32:16.999Z

I noticed this issue while looking through EIPs on the Ethereum Improvement Proposals website, too! And it’s not the only stagnant EIP that’s been implemented by clients.
For example, I found EIP-1186: RPC-Method to get Merkle Proofs. EIP-1186 is the standard method for creating Merkle proofs for Ethereum state trie nodes, and I believe most (if not) all Ethereum L2s (and execution clients) have implemented it. Still, the website shows it hasn’t been finalized yet.
I’m sure there are some others I must have forgotten, but there are definitely one or two EIPs/ERCs that are stagnant but have been widely implemented. Probably helps to push them through if folks have tacitly agreed to adopt a common standard.

Author: yperbasis
Date: 2024-04-09T19:15:11.274Z

EIPs for Pectra - Erigon’s stand
The members of the Erigon Team have considered the Pectra candidates, over and above the already included ones.
The EIPs have been categorized as “Favour”, “Neutral”, and “Against”. The following is a summary of our perspectives on these EIPs:




EIP
Comments




[Favour]EOF
- Speeds up EVM by eliminating the need for the jump destination analysis- Opens the way for potential future improvements such as EVMMAX


[Favour]EIP-3074: AUTH and AUTHCALL opcodes
- A good step towards account abstraction and working around things like sponsored transactions- Better than alternative EIPs in the direction


[Neutral]EIP-2935: Save historical block hashes in state
- Good for light clients - a step towards including ETH protocol within the state- Not urgent- Likely to be modified later to include changes/hacks for Verkle


[Neutral]EIP-7212: Precompile for secp256r1 curve support
- Has applicability for the listed protocols (Apple’s secure enclave, passkeys, android keystore, etc.) and may welcome developers to build efficient apps around them- May not be popular enough yet, viz. a viz Ethereum application


[Neutral]EIP-7547: Inclusion lists
- We do support the idea of having a feature to work around the possible censorship of transactions- Given the practical scenario of proposer-builder separation, this is a welcome step. We also don’t necessarily think that MEV alone can lead to exclusion of transactions


[Against]5806: Delegate Transaction
- The storage problem could create a bad UX


[Against]5920: PAY opcode
- This goes against the assumptions of most smart contracts, where something is supposed to be triggered in response to an incoming value transaction


[Against]EIP-6404, EIP-6465, EIP-6466SSZ-(Transaction /Withdrawals /Receipts root)
- The change in the formats introduces unnecessary additional complexity for the hard fork in terms of data formats, associated tests and many challenges of debugging


[Against]EIP-6913: SETCODE instruction
- Goes against Ethereum’s principles in general- Introduces challenges in UX as it makes it possible to change contracts even beyond known upgrade patterns


[Against]EIP-6914: Reuse validator indices
- Messes up the flow in the code for maintaining the state and indices, especially for historical indices


[Against]EIP-7377: Migration Transaction
- Allowing EOAs to deploy smart contracts onto their accounts is a convoluted task, considering factors like security and upgradeability of general complexities of smart contracts. Potentially dangerous with not many upsides


[Against]EIP-7545: Verkle proof verification precompile
- This should be done in the same upgrade as Verkle (Osaka). Otherwise, it can bind us to a potentially suboptimal early design


[Against]EIP-7609: Decrease base cost of TLOAD/TSTORE
- The updated costs are too low

Author: Nerolation
Date: 2024-04-09T21:18:22.088Z

LukaszRozmej:

There is some community push for increasing gas limit.


Citing Lukasz as the topic of “increasing the gas limit” is more prevalent than ever, thinking of recent pushes like https://pumpthegas.org/ .
Furthermore, there’s already an EIP for increasing the blob count, which might also need a block size reduction as a prerequisite.
In addition, parts of the community have expressed clear demands to increase the gas limit and/or increase the blob count, and they must not be ignored (thinking of the upcoming year(s)).
While the current max block size doesn’t leave much room for such increases, EIP-7623 proposes to increase the calldata costs for calldata-heavy transactions, thus reducing the max block size from 3.5 MiB (incl. blobs) to 1.9 MiB.
The goal of the EIP was to keep the impact on users as small as possible while still achieving the goal of reducing the max. possible block size. Find the latest analysis on the EIP here:
https://nerolation.github.io/eip-7623-impact-analysis/index2.html
The changes needed are very small. Same for the impact (99% of user won’t feel any difference) and the majority of those 1% that are affected are users that put messages into tx (so there are better alternatives than Ethereum L1 anyway). Some non-DA use cases that are affected are big proofs like STARKs (~30% more gas) or on-chain merkle-proofs.
In my opinion, EIP-7623 paves the way for further scaling and should be included in Pectra.

Author: etan-status
Date: 2024-04-17T13:23:14.130Z

Extending on SSZ EIPs:

EIP-7495: SSZ StableContainer (dependency of EIP-6493)
EIP-7688: Forward compatible consensus data structures (unlocks forward compatible CL verifiers)

Furthermore, light client EIPs:

EIP-7657: Sync committee slashings (synergizes with max-eb)
EIP-7658: Light client data backfill (unlocks decentralized beacon node syncing)

Author: radek
Date: 2024-04-22T08:13:17.859Z

Is there any support or opposition to include MULDIV instruction EIP-5000: MULDIV instruction ?

Author: matt
Date: 2024-04-22T21:08:12.707Z

@radek I think the window for proposing EIPs in Pectra is pretty close to finished. If you would like to see this included, you will need to find a champion to present on ACD this week.

Author: radek
Date: 2024-04-23T14:26:34.969Z

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

Author: charles-cooper
Date: 2024-05-09T14:10:36.364Z

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

Author: lettucer
Date: 2024-06-20T04:27:00.613Z

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.

Author: wminshew
Date: 2024-07-02T20:04:45.979Z

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

Author: abcoathup
Date: 2024-09-03T04:52:47.358Z

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.

Author: abcoathup
Date: 2024-09-07T01:48:27.649Z

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.

Author: timbeiko
Date: 2024-09-12T18:16:28.940Z

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

Author: TimDaub
Date: 2025-03-18T16:44:11.142Z

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 Provider Ring


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?

Author: TimDaub
Date: 2025-03-18T16:50:43.941Z

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

Author: moodysalem
Date: 2025-03-18T17:06:02.642Z

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.

Author: TimDaub
Date: 2025-03-18T17:08:28.970Z

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

Author: moodysalem
Date: 2025-03-18T17:48:53.682Z

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.

Author: TimDaub
Date: 2025-03-18T17:59:55.601Z

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?

Author: TimDaub
Date: 2025-03-18T19:55:20.131Z

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

Author: CMG
Date: 2025-03-25T10:07:30.229Z

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

Author: CMG
Date: 2025-03-26T15:50:24.908Z

Anyone? Looking for this info urgently.

Author: timbeiko
Date: 2025-03-26T16:01:25.802Z

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