Use appropriate EVM version for a particular chain - eg Celo

[ryestew]

Some chains don't use the opcodes in the latest EVM upgrade - so in Remix, the latest EVM version, is selected by default but then when a user selects a chain, like Celo, that doesn't use some of the opcodes in the latest EVM, the contract won't deploy and you get an error like this:

The complicating factor is that Remix doesn't know where you'll deploy to when you are compiling. If it did, and if there was a list of chains and their latest EVM compatible version and if this list was up to date, then Remix could set the EVM when compiling to the correct version.

But also when I use the Paris EVM and deploy to Alphajores, I get an RPC error.

Describe the solution you'd like A new workflow should be introduced where the Remix is told the chain the contract will be deploying to.

[yann300]

Proposition of workflow:

• We internally store a mapping chainid <=> evmVersion.
• When a chain is switched to, we check the current chain_id. If the current selected evm_version in the solidity compiler doesn't match the one in the mapping, we automatically switch to it, and show a msg in the terminal switching the solidity compiler to a compatible evm version. Please recompile the contract.

[LianaHus]

I would say not only the terminal but a toaster would make even more sence

[ryestew]

@LianaHus - your idea of using the toaster seems fine - but weren't we trying to minimize toaster use? Even if we are, is this example a good one for employing a toaster?

[GigaHierz]

Adding the case of, when the file uses a higher version, that can't be compiled through remix.

In that case, we could have a toast that says:

"for your chain only the evm_version below is available, please downgrade your file"

Or how would you handle that?

[LianaHus]

@LianaHus - your idea of using the toaster seems fine - but weren't we trying to minimize toaster use? Even if we are, is this example a good one for employing a toaster?

IMHO this is when it is still appropriate to use it and yes you are right, we try to minimize it.

[LianaHus]

Adding the case of, when the file uses a higher version, that can't be compiled through remix.

In that case, we could have a toast that says:

"for your chain only the evm_version below is available, please downgrade your file"

Or how would you handle that?

I would switch automatically and then to inform. We switch sol version based on pragma, but the logic there should be rethinked

[ryestew]

@GigaHierz - Is your comment is in the case of a chain that uses opcodes that are not yet merged into the EVM? I ask because you say that the file uses a "higher version". Or is it in the case where soon after a merge, there could be a delay before the latest EVM is available in Remix?

[GigaHierz]

Hi @ryestew , I realize I moved into a different conversation.

In my last message, I was referring to compiler versions, as a workaround that some people proposed was to use compiler versions lower than 0.8.20 and I was referring to how it would work if we would adapt the compiler versions, in case someone chooses a higher version.

Now, going through the conversation again, I realize we are talking about the EVM version.

So actually, nothing to add to that proposal. The proposed solution sounds good to me.

One other question would actually be, what opcodes are not available on Celo and if that will change with Celo's migration to a L2. Alfajores has already been migrated to an L2 so the error message you added above is the same as I am getting when deploying on Alfajores but different from the one that I am getting when deploying to Celo Mainnet.