Title: Cancun_Network_Upgrade_Meta_Thread
Category: Magicians

Author: timbeiko
Date: 2022-12-08T17:49:01.336Z

Cancun Network Upgrade Meta Thread
On ACDE#153, we agreed to try out Network Upgrade Meta Threads for Cancun.
Instead of creating a new thread, we can repurpose this one given there were already some comments here. We can use this to discuss things like:

What should be the main priority/priorities for the upgrade;
When, roughly, should we aim for the upgrade to happen, and the tradeoffs of including a marginal feature vs. delaying;
How to split multi-upgrade features across >1 upgrade, and the implications of including a subset of those features in a specific upgrade

Included EIPs (June 12, 2023):
On ACDE#163, the scope of the Cancun upgrade was finalized. The list of included EIPs can be found in cancun.md:


EIP-1153: Transient storage opcodes
EIP-4788: Beacon block root in the EVM
EIP-4844: Shard Blob Transactions
EIP-5656: MCOPY - Memory copying instruction
EIP-6780: SELFDESTRUCT only in same transaction


EIP proposals (May 24, 2023):


Click to expand
EIPs with a  are formally included for Cancun. EIPs with a  are being considered for inclusion by client teams. EIPs with a  have been rejected by teams for this upgrade. These are tracked in the Cancun spec. In case of differences between what’s listed here and in the spec, the spec is right.
Proposed EIPs list

EIP-4844 
SELFDESTRUCT removal

EIP-6780 
EIP-4758
EIP-6046
EIP-6190


EIP-5920
EIP-1153 
EIP-2537 
EIP-4788 
EVMMAX EIPs

EIP-6601
EIP-6690


SSZ changes:

EIP-6475 
EIP-6493 SSZ signature scheme 
EIP-6465 withdrawals_root
EIP-6404 / EIP-6466 transactions_root + withdrawals_root


EIP-5656: MCOPY - Memory copying instruction
EIP-6193: SETCODE



EOF changes ❌

EIP-663
EIP-3540: EVM Object Format (EOF) v1
EIP-3670: EOF - Code Validation
EIP-4200: EOF - Static relative jumps
EIP-4750: EOF - Functions
EIP-5450: EOF - Stack Validation


Note: EIP champions who’d like to propose their EIP for Cancun should add the cancun-candidate tag to a post about the EIP on this forum.


Original Post (Dec '22)


Click to expand
Similarly to what we did for Shanghai, I propose using this thread to discuss how we should go about choosing EIPs for the post-Shanghai EL upgrade, Cancun.
At the very least, EIPs which wish to be considered for the upgrade should add the cancun-candidate to either their existing EthMagicians topics, or create a new one focused on Cancun consideration.
For context, please refer to AllCoreDevs 151. Here is a summary posted to the R&D discord:
Screenshot 2022-12-08 at 9.50.34 AM1740×926 225 KB
and a relevant Cancun comment by @protolambda:
Screenshot 2022-12-08 at 9.51.07 AM1670×366 79.6 KB
And here were some proposals shared on in the ACDE agenda comments:

EthereumJS Shanghai/Cancun Proposal
@protolambda Shanghai/Cancun Proposal

Author: axic
Date: 2022-12-08T18:07:00.442Z

I’d like to raise that perhaps the discussions around SELFDESTRUCT may benefit from a revival. There are two bigger proposals on the topic: EIP-4758 and EIP-6046.
A new analysis was shared lately by @jwasinger.

Author: leonardoalt
Date: 2022-12-08T18:52:08.699Z

Solidity would like to propose EIP-663 for Cancun. It has been EFI before in 2019-2020, dependent on immediate arguments. EOF provides that trivially, so it’s fair to say that with EOF 663’s issues become resolved. It’s supported by Solidity, Vyper and Huff, the main direct users of 663. I need to check with Fe as well, but I don’t think they’d be against because they currently compile to Yul which would benefit from this. With 663:

All languages can save gas by not moving local variables to memory when they don’t fit on the reachable part of the stack anymore.
Solidity specifically can cut a big chunk of its roadmap short. The item of “solving stack-too-deep errors”, which include complex optimizers and transformations would simply be done. This also benefits any other language that wishes to optimize local variables by always keeping them on the stack. This consequently brings security advantages by avoiding complex compiler behavior.

If EOF goes in Shanghai, I don’t think it would be possible to add 663 as well.
If EOF goes in Cancun, I think there would be time to add 663 as well given the time until then and how simple it is.

Author: Pandapip1
Date: 2023-01-08T00:09:37.434Z

I would like to propose EIP-5920: PAY opcode. I won’t provide a motivation here, since you can just read the motivation section of the EIP itself.

Author: Pandapip1
Date: 2023-01-08T00:12:47.040Z

In relation to the selfdestruct stuff, I would like to propose EIP-6190 as a non-breaking selfdestruct solution.

Author: non-fungible-nelson
Date: 2023-01-19T17:39:53.810Z

Thanks for creating this Tim. Some opinions my own and some the Besu team’s:

Priorities should be EOF and 4844, (and whatever consensus we reach on SELFDESTRUCT). The EIP grab-bag approach from Shanghai, while useful, should be limited if we can. There are often many details that come up during the implementation phase and I think it would be best to avoid creep on this already large fork.
I think the progress on 4844 in the workshop should drive a timeline. We initially dubbed this a fast-follow fork, which sounds like early 2H. With Shanghai, timelines are dictated by our need to ship withdrawals. While we can accumulate some tech-debt in Shanghai for withdrawals as we have a chance to correct it in Cancun, more pervasive protocol changes in 4844 and EOF will be quickly enshrined tools, langs, and live contracts. To this end, delays are more prudent than shipping “something,” especially with EOF and EVM version requiring support in clients and languages.
I have no preference on this - protocol schedules are flexible. We can ship code that lives dormant for a while on Mainnet while we iron it out elsewhere. Weakly in favor of ship often, test often approach.

Matt

Author: moodysalem
Date: 2023-01-20T05:33:41.330Z

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

Author: abcoathup
Date: 2023-01-20T06:24:19.919Z

To increase Layer 2 adoption we need lower cost transactions, hence the need for EIP4844.
Shapella was focused on withdraOWLs .
Dencun (Cancun + Deneb) should focus on blobspace .
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

Author: Pandapip1
Date: 2023-01-20T17:22:36.037Z

Ethereum Improvement Proposals


EIP-5920: PAY opcode
Introduces a new opcode, PAY, to send ether to an address without calling any of its functions





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

Author: hilmarx
Date: 2023-01-28T14:17:03.383Z

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.

Author: ralexstokes
Date: 2023-02-23T21:53:11.285Z

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

Author: jwasinger
Date: 2023-02-26T20:04:26.393Z

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.

Author: etan-status
Date: 2023-03-02T14:30:29.610Z

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.



HackMD



SSZ Meta for Cancun - HackMD

Author: timbeiko
Date: 2023-04-13T16:30:00.726Z

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

Author: shemnon
Date: 2023-04-17T15:50:50.519Z

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.

Author: LukaszRozmej
Date: 2023-04-18T09:01:39.671Z

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

Cancun:


Yes: 4844, 6780, 1153
Maybe but more yes: 2537, 4788
Maybe but more no: 5920


Next post-cancun hardfork: SSZ, EOF, EVMMAX
Next-next post-cancun hardfork: Verkle

Author: timbeiko
Date: 2023-04-18T15:58:33.821Z

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

Author: jflo
Date: 2023-04-19T17:32:51.397Z

timbeiko:

EIP-6466


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

Author: wjmelements
Date: 2023-04-25T17:12:20.522Z

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.

Author: etan-status
Date: 2023-04-27T13:59:54.531Z

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.

Author: charles-cooper
Date: 2023-04-27T14:30:40.929Z

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.

Author: timbeiko
Date: 2023-04-27T15:41:21.463Z

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

Author: charles-cooper
Date: 2023-05-11T14:16:31.837Z

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

Author: timbeiko
Date: 2023-06-12T20:58:17.312Z

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

Author: KeeJef
Date: 2023-06-21T01:24:14.760Z

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.

Author: abcoathup
Date: 2023-06-22T08:02:27.128Z

KeeJef:

Just wanted to voice my support of for inclusion of EIP-2537 in Cancun


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