Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VIP: EVM Ruleset Switch #1230

Closed
fubuloubu opened this issue Feb 5, 2019 · 11 comments · Fixed by #1783
Closed

VIP: EVM Ruleset Switch #1230

fubuloubu opened this issue Feb 5, 2019 · 11 comments · Fixed by #1783

Comments

@fubuloubu
Copy link
Member

@fubuloubu fubuloubu commented Feb 5, 2019

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

This comment has been minimized.

Copy link
Collaborator

@jacqueswww jacqueswww commented Feb 5, 2019

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

This comment has been minimized.

Copy link
Member Author

@fubuloubu fubuloubu commented Feb 5, 2019

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

This comment has been minimized.

Copy link
Collaborator

@jacqueswww jacqueswww commented Feb 5, 2019

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

This comment has been minimized.

Copy link
Member Author

@fubuloubu fubuloubu commented Feb 5, 2019

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

This comment has been minimized.

Copy link
Collaborator

@jacqueswww jacqueswww commented Feb 5, 2019

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

This comment has been minimized.

Copy link
Member Author

@fubuloubu fubuloubu commented Apr 24, 2019

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)

@fubuloubu fubuloubu added this to To do in Release Candidate! via automation Jun 13, 2019
@charles-cooper

This comment has been minimized.

Copy link
Collaborator

@charles-cooper charles-cooper commented Aug 6, 2019

vyper --evm-version=istanbul
vyper --evm-versions
> Byzantium (default), Constantinople, Istanbul
@charles-cooper

This comment has been minimized.

Copy link
Collaborator

@charles-cooper charles-cooper commented Aug 6, 2019

add version info (availability, gas cost) to opcodes

@fubuloubu

This comment has been minimized.

Copy link
Member Author

@fubuloubu fubuloubu commented Oct 27, 2019

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

This comment has been minimized.

@charles-cooper

This comment has been minimized.

Copy link
Collaborator

@charles-cooper charles-cooper commented Oct 28, 2019

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

Release Candidate! automation moved this from To do to Done Jan 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
3 participants
You can’t perform that action at this time.