ethereum
Drop support for ancient EVM versions, i.e. for homestead
Came up in https://github.com/ethereum/solidity/pull/12205/files#r743092422.
-
homesteadin particular needs thecanOverchargeGasForCall()workarounds, which complicate code (although to be fair it's not that bad) - the new Yul-EVM code transform currently cannot guarantee not to reorder the
gasopcode (although to be fair it could probably be adjusted, s.t. it can, but that would probably mean some more invasive special case handling)
So while that's not an absolutely strong case, maybe it still makes sense to consider dropping support. For that the main consideration is probably:
Are there any live chains that run homestead, resp. any users that may rely on new compiler versions to be able to generate homestead-compatible bytecode?
If not, there's little reason for not dropping the support.
This would be breaking, right?
Probably - although I guess there's no precedent and it might be fair to decide that it's not - I guess we'll only drop support, if we're reasonably sure that doing so in practice doesn't break anything anyways :-).
The issue I see is that Solidity is used by many other chains and we want to avoid the need for various forks to emerge. I know that there is such differentiation between the various chains, mostly they may not implement some recent features from Berlin/London, or they implement features non existing on mainnet (however these are mostly in a way, like precompiles, which does not require a change in the compiler)
Now if we start dropping support for older mainnet releases, we may find ourselves in a spot where we drop support for some chains. I do not think this applies to homestead, as I'd imagine most chains are on Byzantium-compatibility (for revert/staticcall/returndata) or even Constantinople-compatibility (for create2).
In the end I think it is important to keep the above in mind.
I don't think this is such a big problem. Currently the strategy to just have non--optimized code (or code with stack errors) for ancient versions works well enough in my opinion.
If we switch to non-optimized code only, then it's really a non-issue. It would just both be annoying to have to adjust the new code transform to handle this, as well as having to keep the complexity of the stack optimizations in the old code transform because of this...
Looks like Vyper will be dropping everything older than istanbul in the next release. The PR for that is even already merged: https://github.com/vyperlang/vyper/pull/3470.
We did ask around at least a bit already, whether this would be a problem for anyone, but nobody weighed in so far? We could emit a "deprecated" warning soon to give people a chance to cry out.
A deprecation warning sounds like a good idea.
Also, wouldn't hurt to announce on Twitter that we're planning to do that.
Implementation note: also drop the old Yul->EVM transform (see https://github.com/ethereum/solidity/issues/15641#issuecomment-2587504944).
I'm wondering if our support for pre-byzantium EVMs even works (in the sense that the produced bytecode would run on such an old EVM). Only that fork introduced REVERT (EIP-140: REVERT instruction), but we seem to be using it unconditionally on all versions. Even compiling something as simple as contract C {} produces bytecode that contains two reverts. That's still reproducible with --evm-version homestead and on compiler versions down to 0.5.0. Earlier ones either do not have the CLI flag or hang when I try to use it.
But if that's the case, I would have expected that to come up in tests and it never did. And we do have some semantic tests specifically for homestead, like return_dynamic_types_cross_call_out_of_range_1.sol. Just running it should have revealed the problem, assuming that evmone properly disables REVERT and from a quick look at its code it seems that this should be the case.