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
0 ·
Comments
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
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