Ethereum Community Forum
Home › Protocol and Client discussion
Vega Finally Unleashed! Fine-tuned performance and power consumption in a single chassis.

EVM version stored alongside contracts

MarioFortierMarioFortier Boston, MAMember Posts: 30 ✭
edited September 2014 in Protocol and Client discussion
There should be a way to identify which EVM version a contract was written for.

This will make possible to:
- Maintain compatibility while EVM specs evolves.
- Allow not-yet upgraded full-node to keep working (do not execute transaction on contract not supported).

I hope this will be considered for the first release.

\Mario
· Share on FacebookShare on Twitter

Comments

  • StephanTualStephanTual London, EnglandMember, Moderator Posts: 1,282 mod
    Unlikely. If the EVM-code changes, a hardfork would be required. So technically, "not-yet upgraded full-nodes" *would* indeed keep working, and that's a bad thing.
    · Share on FacebookShare on Twitter
  • MarioFortierMarioFortier Boston, MAMember Posts: 30 ✭
    Debatable but granted. Disabling all the full-nodes not upgraded is one way of forcing these to be upgraded (I assume there is some version field done at another level to make that possible).

    Still, would you agree there is some value to match a contract with the same EVM version/behavior it was originally written/tested/agreed upon by its users?

    \Mario


    · Share on FacebookShare on Twitter
  • MarioFortierMarioFortier Boston, MAMember Posts: 30 ✭
    edited September 2014
    I have seen often in the Telco industry that code for legacy protocol is left untouched. Sometimes it goes as far as cut&paste&rename as a starting point for implementing a new version (and preserve the legacy code). The code selected to be run is driven by the version. This is a good way to lower risk of breakage on something that the customer assumes will just keep working as before.

    This is an example of what I mean by running contracts against a matching EVM version. It is more flexible and safer than forcing the developers to always modify a single EVM code that must keep working for all release that ever existed.

    ===

    Furthermore, without versioning in the first release you forever close the door on doing things "differently". As an example, all bytecode/behavior introduced will have to be always present, even if becoming irrelevant in light of a new design. With versioning the legacy bytecode/behavior has to exists only for the older matching contracts+EVM.

    \Mario
    · Share on FacebookShare on Twitter
Sign In or Register to comment.