Cancun Network Upgrade Meta Thread

Process Improvement
7

I’d like to propose EIP-1153 for inclusion in Cancun. I’ve updated the candidate thread with the latest status. Further progress on EIP-1153 is blocked by marking it for inclusion, allowing it to be part of devnets and giving client developers a reason to finish code reviews and merge the outstanding PRs.

And some meta commentary: the main reason EIP-1153 is not in Shanghai is that EOF was added in December and removed a month later. I think this is a failure of prioritization that deserves more discussion. I’d suggest this time around not committing to anything else (other than EIP-4844) for which the spec is not finalized, and EOF is still figuring out parts of the spec (e.g. just a week ago DELEGATECALL into legacy code was brought up).

2 Likes
8

To increase Layer 2 adoption we need lower cost transactions, hence the need for EIP4844.

Shapella was focused on withdraOWLs :owl:.
Dencun (Cancun + Deneb) should focus on blobspace :blowfish:.
The timeline for Cancun should be based on EIP4844 readiness. e.g. May/June.

Any additional EIPs should have finalized specs and not add significant delay (e.g. more that 1-2 months) to the delivery of Cancun, otherwise they should be candidates for inclusion in the Prague upgrade later in 2023 or early 2024.

EIPs to add to Cancun in addition to EIP4844

Assume finalized EIP spec and EIPs don’t add significant delay to delivery of Cancun.

  • EIP1153: Transient storage opcodes
  • EIP2537: Precompile for BLS12-381 curve operations
  • EOF
  • Other (reply with details)

0 voters

9

It’s simple and the spec is basically finalized. There’s a PR to add it to nethermind: Add EIP-5920 by Pandapip1 · Pull Request #5166 · NethermindEth/nethermind · GitHub

2 Likes
10

EIP2537 or a new implementation for a BLS precompile would be great in order to make it easier for decentralized off-chain networks Lido or Gelato to utilize BLS for threshold signatures.

4 Likes
11

EIP-4788 keeps coming up and I think would be a relatively small change that unlocks a lot of benefits so should be CFI in Cancun.

It would also be nice to unlock some kind of BLS arithmetic in Cancun, either via EIP-2537 or something like EVMMax (which requires EOF AIUI).

4 Likes
12

For reference, the latest proposal for EVMMAX is documented in the EIP-5843 discussion thread.

A new spec is being prepared which addresses issues identified in 5843.

1 Like
13
  • EIP-6493 SSZ signature scheme
  • EIP-6465 withdrawals_root
  • EIP-6404 / EIP-6466 transactions_root + withdrawals_root

These would be great to have in Cancun, still being designed though, specs not final.

2 Likes
14

On ACDE159, we agreed to discuss potential Cancun EIPs on the next call, scheduled for April 27, 14 UTC.

I’ll keep track of EIPs proposed for the upgrade in the first post of this thread. If you’d like to propose an EIP and it’s not part of the list, please reach out to me. You can add the cancun-candidate tag as well to make it easy for people to see all proposed EIPs’ threads on a single page here :slight_smile:

1 Like
15

Can we move EIP-663 into the EOF group? The current revision of the spec depends on immediate arguments, which is only viable in an EOF container.

1 Like
16

Nethermind internal core dev discussions go this way in terms of priorities, what is deliverable, size, state of implementation:

  1. Cancun:
  • Yes: 4844, 6780, 1153
  • Maybe but more yes: 2537, 4788
  • Maybe but more no: 5920
  1. Next post-cancun hardfork: SSZ, EOF, EVMMAX
  2. Next-next post-cancun hardfork: Verkle
4 Likes
17

Moved the EIP, @shemnon! And thanks for sharing @LukaszRozmej :slight_smile:

18

This one claims to depend on 6475, which introduces Optionals to the SSZ spec.

19

If SELFDESTRUCT is broken such that it can no-longer remove code (eg via EIP-6780), I want to include EIP-6913 (SETCODE) to preserve code mutability.

1 Like
20

The minimal parts for Cancun should be EIP-6493 SSZ signature scheme, and EIP-6475 SSZ Optional definition. Not deciding on how these should look for Cancun makes it difficult to change in the future.

EIP-6465 and EIP-6404 / EIP-6466 can be addressed later, the overhead is same whether done in Cancun or in E-Fork.

21

I’d like to propose inclusion of EIP 5656 (MCOPY) in Cancun. I don’t think there is any contention about the spec or its usefulness, it’s easy to understand and implement, it would enable better codegen for batch memory copies in compilers, and it already has an open PR to implement in geth.

1 Like
22

Thanks, @charles-cooper - I’ve updated the first post to include this, as well as the decisions made in ACDE#160. See the spec PR: Update Include and CFI'd EIPs by timbeiko · Pull Request #754 · ethereum/execution-specs · GitHub

3 Likes
23

evmone has merged support for MCOPY: https://github.com/ethereum/evmone/pull/629

4 Likes
24

Note, the scope for Cancun was finalized on ACDE last week. Here’s a PR which updates the list of EIPs: Update included EIPs list by timbeiko · Pull Request #792 · ethereum/execution-specs · GitHub

1 Like
25

Just wanted to voice my support of for inclusion of EIP-2537 in Cancun, would give much greater first party support for BLS. Using the alt-bn128 precompiles for BLS currently feels a little hacky.

1 Like
26

Cancun scope was finalized. Prep your case for inclusion in the following upgrade Prague.