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
Current EIP proposals (May 24, 2023):
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.
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.
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.
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).
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
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