Define and document a policy for changing the default evmVersion used by solc

[fvictorio]

See discussion in #4232.

Top 10 chains by TVL makes sense. An alternative idea is to do something similar to what's done in the web, where you decide based on the percentage of adoption. So, if (say) 95% of the EVM TVL is in chains which support shanghai, we change it. This sounds like a great feature for evmdiff.com to have.

[pcaversaccio]

Top 10 chains by TVL makes sense. An alternative idea is to do something similar to what's done in the web, where you decide based on the percentage of adoption. So, if (say) 95% of the EVM TVL is in chains which support shanghai, we change it. This sounds like a great feature for evmdiff.com to have.

tagging @mds1 here since he's spearheading the evmdiff.com initiative :)

[mds1]

Hey all, skimmed the linked convo. So IIUC the goal of this policy is to minimize the chance that devs deploy contracts that cannot work due to unsupported opcodes. Going to think out loud a bit here...

Given that goal, I think what we want is "top 10 chains by <some developer-related metric>" to minimize the number of affected devs. Of course any metric we choose can be gamed and will have flaws. TVL is probably a reasonable enough proxy for developer actively, and it's nice because it's easy to measure. But it is easily swayed by whales, and it wouldn't surprised me that TVLs are artificially inflated due to illiquid tokens with unrealistic prices. Regardless, it's an easy choice for a first pass.

Longer term something like "number of contracts deployed" over a time period might be more representative, but that is probably harder to get data for (and still gameable). "Total gas used" is a similar metric, but gets tricky since e.g. arbitrum has different gas metering

FWIW I do want to add a caniuse.com-like view to EVM Diff, so you can see all chains that support a given EIP/opcode, but I don't have a timeline for that

[alcuadrado]

I agree with everything you said. We can have a simple first iteration and then improve it. Maybe we can ping the etherscan or tenderly guys if we need a different metric in the future, they are both normally really helpful.

re cainisused.com: that'd be so awesome!

[pcaversaccio]

Longer term something like "number of contracts deployed" over a time period might be more representative, but that is probably harder to get data for (and still gameable). "Total gas used" is a similar metric, but gets tricky since e.g. arbitrum has different gas metering

FWIW on the "# of contracts deployed" I built once a Dune Dashboard on this: https://dune.com/pcaversaccio/smart-contract-deployment-statistics

Don't get fooled by the Binance numbers due to the gas tokens. But this might also help as a data point for the decision long-term :-D.

[fvictorio]

canipush0.com

[pcaversaccio]

😄

[mds1]

Amazing idea. Just bought it, won't let you down 🫡

[pcaversaccio]

canitstoretload.com soon :-D

[mds1]

Came across https://twitter.com/nikzh/status/1700499035277201475 which could be a useful tool for determining the top chains then checking their support

[SKYBITDev3]

The policy should include something about version numbering (I think a patch version number increment is not appropriate), and maybe give the user a chance to choose. See #4391