EVM Version Identifier

[chriseth]

A version identifier or EVM identifier should be added to the code of each contract to facilitate virtual machine upgrades and allow different virtual machines.

With upcoming breaking changes to the functionality of the EVM, it makes sense to add a field that represents the version or type of EVM that should run the given code. This would allow to introduce breaking feature changes without harming older contracts (breaking security changes like #150 would of course also affect older contracts). This is especially useful if we want to change the EVM due to performance reasons and could allow changing the gas costs of individual opcodes (because they can be implemented faster in that particular EVM) and even introducing whole new features of the EVM (like ewasm).

Any time code is loaded and run (i.e. at a call, create or beginning of a transaction), the EVM version number is extracted from the code or that account and the relevant VM is started. If the EVM is not know, this results in an OOG exception.

Drawbacks of this proposal are that we have to support older versions of the EVM, although this is a choice that is made during a hard fork: We can chose to drop older versions and handle that in the same way as it was done previously: Either compile old code to new code or just force the new rules on the old system.

Implementation details:

If the code starts with 0xef, the byte (ewasm uses four bytes) that follows this is the version number, both are ignored when executing the code. If it does not start with 0xef, use the homestead VM, which is version number 0.

[chriseth]

This should be combined with ewasm/design#2 - what is the current status on that, @axc?

[wanderer]

in ewasm currently, wasm has an identifier (that is invalid to evm) and EVM is left unchanged. Another option is to identify metering types instead of VM types. This is proposed here ewasm/design#50

[wanderer]

also here is the propsed change for identifies in ewams ewasm/design#39

[chriseth]

Thanks, updated the description.

[axic]

If the code starts with 0xef

I think it would be nice referring to this as INVALID_OPCODE (see #141).

the byte (ewasm uses four bytes) that follows this is the version number

The eWASM magic is 0x00, 0x61, 0x73, 0x6d. Therefore you would end up with 0xef, 0x00, .. which would be considered version 0 (homestead).

[axic]

This should be combined with ewasm/design#2 - what is the current status on that, @axc?

The rules are described here: https://github.com/ewasm/design/blob/master/vm_semantics.md

[tawaren]

Is their already a decission if this is or some similar approach will be included and if so when?
I'm asking because for a project of mine I need to write a contract code verifier that in the code specified to CREATE loads code with EXTCODECOPY and analyses it to ensure it does not include opcodes like for example SSTORE and if they do it aborts. If know a future hardfork includes a new opcode say SSTOREBYTES my verifier will not recognize it as store related opcode and approves the code, which would compromise not only all new contracts after the hardfork, which the verifier approved, but in my case it would compromise all the contracts that the verifier approved in the past.

[SergioDemianLerner]

You can use RSK's code header. Defined here in the code:
https://github.com/rsksmart/rskj/blob/master/rskj-core/src/main/java/org/ethereum/vm/program/Program.java#L1236

This way we can keep ETH in sync with RSK. Soon I will publish our RSKIPs where the explanations are.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.