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

Use Cancun by default #4851

Closed
7 tasks done
fvictorio opened this issue Feb 12, 2024 · 5 comments
Closed
7 tasks done

Use Cancun by default #4851

fvictorio opened this issue Feb 12, 2024 · 5 comments
Assignees
Labels
status:ready This issue is ready to be worked on

Comments

@fvictorio
Copy link
Member

fvictorio commented Feb 12, 2024

We'll do this after Cancun is enabled in mainnet.

To-do:

  • Use Cancun as the default hardfork in the Hardhat network config
  • Remove the code that skips Cancun in the test/.../default-config.ts test
  • Add the proper entry to the mainnet hardfork history in src/.../default-config.ts
  • Uncomment the Cancun-related tests in forking-different-hardforks.ts
    • Add the cancun block number
    • Update the values used in the tests (those are the ones that I used for sepolia, so they will be wrong for mainnet)
    • Add tests for the beacon root contract
@github-actions github-actions bot added the status:ready This issue is ready to be worked on label Feb 12, 2024
@kanej kanej self-assigned this Mar 8, 2024
@cameel
Copy link

cameel commented Mar 8, 2024

Are you seeing any CI failures with EVM version set to cancun? In Solidity we noticed Hardhat test suite failing with the latest version of the compiler when we switched to cancun by default (which we want to do in a release that will concide with Cancun activation on mainnet).

We're not sure if it's just some bit needed for full Cancun support still missing in Hardhat or maybe one of the still unreleased changes in solc that triggers this (the IR codegen starting to use mcopy for copying memory is one suspect).

The change also results in massive failures in other external projects we have hooked into CI via Hardhat, like OpenZeppelin.

@matheusaaguiar will soon open issues with more details and repros, but you can see the breakage in the failing jobs of ethereum/solidity#14907 (all the _ext_ ones).

@fvictorio
Copy link
Member Author

For the record, this is about setting Cancun as the default hardfork of the Hardhat network. We are not going to use it as the default solc target for a while (we are not even using Shanghai as the default solc target yet).

But of course, things should work when Cancun is used as solc's target, so we are going to look into that. Thanks for letting us know!

@cameel
Copy link

cameel commented Mar 12, 2024

An update on the problems on our side. Turns out it actually is related to the default hardfork setting. We only now realized that this setting is completely independent of the EVM version for the compiler and does not default to it. Perhaps it would be a good idea to make it so. In any case, setting it explicitly will probably solve our problem with the external projects we test.

@fvictorio
Copy link
Member Author

Perhaps it would be a good idea to make it so.

We had to be conservative after Shanghai, because people could accidentally deploy contracts with PUSH0 in networks that didn't support it yet. It's not a great solution though; I hope we can do something smarter in future versions.

@r0qs
Copy link

r0qs commented Mar 13, 2024

Hey @fvictorio you might also consider changing this hardcoded setting: https://github.com/NomicFoundation/hardhat/blob/main/packages/hardhat-core/test/internal/hardhat-network/stack-traces/execution.ts#L34 to cancun when switching to it by default. I'm not sure if this is already on your radar, but it's the setting that resolved the failing stack tracing tests for us.

kanej added a commit that referenced this issue Mar 13, 2024
Set cancun as the default config for the hardfork used in Hardhat
network.

Resolves #4851
@kanej kanej closed this as completed in bcce371 Mar 13, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 12, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status:ready This issue is ready to be worked on
Projects
Archived in project
Development

No branches or pull requests

4 participants