Drop support for ancient EVM versions, i.e. for homestead

ethereum / solidity

Solidity, the Smart Contract Programming Language

https://soliditylang.org

GNU General Public License v3.0

23.13k stars 5.73k forks source link

Drop support for ancient EVM versions, i.e. for homestead #12246

Open ekpyron opened 2 years ago

ekpyron commented 2 years ago

Came up in https://github.com/ethereum/solidity/pull/12205/files#r743092422.

homestead in particular needs the canOverchargeGasForCall() 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 gas opcode (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.

cameel commented 2 years ago

This would be breaking, right?

ekpyron commented 2 years ago

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 :-).

axic commented 2 years ago

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.

chriseth commented 2 years ago

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.

ekpyron commented 2 years ago

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...

ekpyron commented 1 year ago

New tendency: even drop everything below constantinople.

cameel commented 1 year ago

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.

ekpyron commented 1 year ago

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.

cameel commented 1 year ago

A deprecation warning sounds like a good idea.

Also, wouldn't hurt to announce on Twitter that we're planning to do that.