Pectra Network Upgrade Meta Thread

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.

2 Likes

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
13 Likes
  • AUTHCALL for empowered EOAs
  • SETCODE for account upgrades post-SELFDESTRUCT
  • Increase codesize limit to 2**16
1 Like

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.

7 Likes

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 :slight_smile:

8 Likes

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.

3 Likes

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.

6 Likes

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.

1 Like

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ā€¦

5 Likes

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.18

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.

6 Likes

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.

4 Likes

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.

2 Likes

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

2 Likes

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

3 Likes

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

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

2 Likes

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.

1 Like

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: EIPs For Nerds #2: EIP-7002 (Execution Layer Triggerable Exits). 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.

2 Likes

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.

1 Like

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: EIPs For Nerds #3: EIP-7251 (Increase MAX_EFFECTIVE_BALANCE).

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.

6 Likes