Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(config): upgrade default evm_version to cancun #8614

Closed
zerosnacks opened this issue Aug 6, 2024 · 1 comment · Fixed by #9131
Closed

feat(config): upgrade default evm_version to cancun #8614

zerosnacks opened this issue Aug 6, 2024 · 1 comment · Fixed by #9131
Assignees
Labels
A-config Area: config T-feature Type: feature T-likely-breaking Type: requires changes that can be breaking T-to-discuss Type: requires discussion
Milestone

Comments

@zerosnacks
Copy link
Member

zerosnacks commented Aug 6, 2024

Component

Other (please describe)

Describe the feature you would like

We should evaluate whether it already makes sense to default to either: cancun (13 Mar 2024) or shanghai (12 Apr 2023) from paris (15 Sep 2022). (source)

The current configuration is:

evm_version = "paris"

The table of https://www.evmdiff.com/features?feature=opcodes shows tstore and tload are not supported on Avalance and Linea but is available on the other rollups. The current support of the entire cancun upgrade on L2s seems largely there, other EVM compatible chains have less support.

For 1.0 I think it also makes sense to establish an expectation that the default we set trails by x months.

Additional context

Considering this is a breaking change and most users have possibly not specified an evm_version this change can introduce unintended side effects.

It may make sense to pin to paris for 1.0 and apply the breaking changes post-release.

@zerosnacks
Copy link
Member Author

cc @grandizzy just noticed that Hardhat also defaults to cancun: https://hardhat.org/hardhat-network/docs/reference#hardfork

I think we can make this change without much issues

@zerosnacks zerosnacks removed the T-blocked Type: blocked label Nov 5, 2024
@zerosnacks zerosnacks assigned zerosnacks and unassigned zerosnacks Nov 5, 2024
@grandizzy grandizzy moved this from Todo to Ready For Review in Foundry Nov 12, 2024
@grandizzy grandizzy self-assigned this Nov 12, 2024
@github-project-automation github-project-automation bot moved this from Ready For Review to Done in Foundry Nov 18, 2024
@grandizzy grandizzy moved this from Done to Completed in Foundry Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-config Area: config T-feature Type: feature T-likely-breaking Type: requires changes that can be breaking T-to-discuss Type: requires discussion
Projects
Status: Completed
Development

Successfully merging a pull request may close this issue.

3 participants