VIP: EVM Ruleset Switch

[fubuloubu]

Simple Summary

People need to produce code for different versions of the EVM

Abstract

Provide an interface to switch the VM rulesets used to compile, validate, and produce bytecode for a given source program.

Motivation

It is important for developers to be able to produce bytecode for different versions of the EVM. This may include for future hardfork implementations (such as constantinople), or for chains that still use past rules (ETC or permissioned networks like Quorum). It might also be eventually useful to specify more granular or custom rulesets via py-evm, but that is out of scope for now.

Specification

Solidity has --evm-version VM_NAME flag:

$ solc --help
...
  --evm-version version
                       Select desired EVM version. Either homestead, 
                       tangerineWhistle, spuriousDragon, byzantium (default) or
                       constantinople.
...

I suggest we use this.

The technical details should be as such:

1. The source program is compiled and/or statically analyzed for features at the AST or IR (LLL) layer
2. Features that are not possible in the chosen ruleset raise an exception
3. Features that have alternative implementations in the chosen ruleset generate that alternative, and note the modification (vs. the default)

Backwards Compatibility

Fully backwards compatible

Dependencies

No dependancies on other VIPs

Copyright

Copyright and related rights waived via CC0

[jacqueswww]

I am happy if we support byzantium onwards, but having to figure out all the differences before that will be a lot of work for minimal gain.

[fubuloubu]

I think a really scalable solution here utilizes py-evm's rulsets, and I think that would alleviate your concern, but I agree that the approach should be to support the latest main-chain primarily

[jacqueswww]

Yeah this would require a lot of works in the lll compile & opcode step. Py-evm's rulesets are not as easy to wield here, have you seen how it's implemented?

[fubuloubu]

Was taking a browse through. My initial thought was to check against the dict of opcodes for existence (to throw an error), then validate if there was an incorrect number of args for the opcode later down the line.

Definitely a lot of work to get it flawless, but arguable very necessary for supporting new hard forks and the like

[jacqueswww]

That seems quite do-able, but then we'd create a dependency on py-evm for the base vyper install. For reference see: https://github.com/ethereum/py-evm/blob/master/eth/vm/forks/byzantium/opcodes.py

I say let's try to see what byzantium -> constantinople switch would look like, and then we take it from there?

[fubuloubu]

Maybe a different way to support this is through a flag with comma-separated EIP numbers that are implemented in the language but not currently enabled in the main chain (but planned for a hard fork)

[charles-cooper]

vyper --evm-version=istanbul

vyper --evm-versions
> Byzantium (default), Constantinople, Istanbul

[charles-cooper]

add version info (availability, gas cost) to opcodes

[fubuloubu]

Going to request that this be first partially implemented thru work on #1654 as an version-specific optimization and #1652 as a version-specific feature, as these should be minimal-impact.

[jacqueswww]

Useful: https://github.com/ethereum/py-evm/blob/master/eth/chains/mainnet/constants.py

[charles-cooper]

implementation-wise, probably cleanest to make a new LLL pseudo-opcode for every new EVM feature we want to support, and then we only need to deal with the versioning at the LLL to EVM translation step, either emulate for older versions (e.g. for SELFBALANCE) or throw if not supported (e.g. CHAINID).