VIP: only support fork rules up to 3 years old

[charles-cooper]

Simple Summary

Only support forks (ex. constantinople, etc) up to 1 year 3 years old

Motivation

Ease of maintenance, and old forks aren't really used, so it doesn't make sense to shoulder the maintenance burden.

Specification

Backwards Compatibility

Lose backwards compatibility with old EVM versions.

Dependencies

If this VIP depends on any other VIPs being implemented, please mention them.

References

Add any references that this VIP might reference (other VIPs/issues, links to blog posts, etc.)

Copyright

Copyright and related rights waived via CC0

[fubuloubu]

Maybe the best approach here would be to support different networks, vs. specific forks

So whatever the latest is across the board for N networks we support, is what we support

[charles-cooper]

i mean eth mainnet is de facto standard. so we should probably just follow that, and then maybe add configurable other networks for new features that haven't made it to mainnet yet

[fubuloubu]

i mean eth mainnet is de facto standard. so we should probably just follow that, and then maybe add configurable other networks for new features that haven't made it to mainnet yet

Some networks like polygon, BSC, fantom, etc. May not support specific new opcodes yet, or may have already added support (berachain added transient storage)

[charles-cooper]

Some networks like polygon, BSC, fantom, etc. May not support specific new opcodes yet, or may have already added support (berachain added transient storage)

how far behind are polygon, BSC, fantom etc typically from mainnet? if it's less than a few months, then we could even not support any non-current EVM versions since our release cadence is typically 1-3 months.

[fubuloubu]

Some networks like polygon, BSC, fantom, etc. May not support specific new opcodes yet, or may have already added support (berachain added transient storage)

how far behind are polygon, BSC, fantom etc typically from mainnet? if it's less than a few months, then we could even not support any non-current EVM versions since our release cadence is typically 1-3 months.

Not completely sure. I think there's at least one example of an alt L1 that does not implement an Ethereum EVM-specific opcode, that might be a year or more out of date

[bobsummerwill]

ETC Cooperative funded the conditional versioning support in Vyper in the first place back in 2020, because at that time ETC was lagging very far behind:

https://etccooperative.org/posts/2020-01-07-vyper-support-comes-to-etc

That is not the case anymore. We've been tracking within 6-12 months since mid-2020, but I could see how some chains could be lagging. Without such support, users would have to use older versions of Vyper, which could be missing security or performance fixes.

From having maintained central tech myself for years, I know the tradeoffs here. The broader the set of versions you support, the better you serve your end users. You always want them to be using the latest or close to latest that they can, but there might be a whole range of reasons you do not know which constrains that for them.

I guess my question is how burdensome having a range of versions supported is? How much conditional code do you have? Is it often painful during testing?

Low level technology is often covered with warts and hacks.

ETC is still "London" and we are not in a rush to implemented "Shanghai", though might do it later in the year. How much difference is there in Vyper for London vs Shanghai?

[charles-cooper]

for vyper, london vs shanghai is mainly the ability to use the PUSH0 opcode. and, we don't have that much conditional code - see hits for check_version() in the codebase.

it does get more complicated the more versions we have. we end up maintaining more conditional code, and there are issues with users sometimes using very old versions when they shouldn't be. i am a bit more concerned with upcoming changes: transient storage, which might result in language changes (ex. #3380 which can't be implemented pre-1153), and EOF, which if and when we need to support it, will be tantamount to having to support two different backends.

[charles-cooper]

per offline discussion with @pcaversaccio, maybe a more reasonable support window would be the last 3 years of fork rules. this means as of today (mar 7 2024) we can drop istanbul support, and next month we could drop berlin support.