#2 + EIP1707 Contract-prefixed EVM versioning

[meowsbits]

Proposed modification to ECLIP-?: Byzantium EVM upgrades (and Tx Receipt status), advocating the contract-prefix scheme for account versioning, as in EIP1707.

Reviews, comments, suggestioned edits welcome.

[meowsbits]

A thought with EVM versioning,

Versioning different VM types in a linear fashiong would mean EVM cannot be updated after for example WebAssembly is enabled.
ethereum/EIPs#1702 (comment)

https://github.com/ethereumproject/ECIPs/blob/4d93484ef702265558b72d35e49ec521f3041f55/ECIPs/ECIP-1040.md#specification

@sorpaas As far as I understand the currently proposed VM versioning scheme(s), it seems to me they rely on assumptions of VM versions being defined by linear hardfork(s); Homestead VM, Byzantium VM, etc.

Is this a correct? If so, what implications might this have for cross-chain contracts and multi-chain clients, as the "Ethereum ecosystem" grows with variations and mutations on the EVM across independent hardfork series?

Is there a way we might be able to systematize a VM "version" that would be more able to describe it's features?

[sorpaas]

@meowsbits Yes. That's why I would suggest to use ethereum/EIPs#1707 instead

[meowsbits]

😕 This is proposing 1707.. or?

[meowsbits]

What I'm seeing for versioning schemes boils down to EVM1, EVM2, EVM3, and so forth...

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.

The limitation with this is that it makes contacts single-network use, right?

Let's say a new opcode MAGIC is proposed. ETH introduces MAGIC to the VM at their 4th iteration of their VM (hardfork Abracadabra). ETC, on the other hand, introduces MAGIC on the 5th iteration of their VM (the Hardfork That Shall Not Be Named).

So now a contract making use of MAGIC on ETH has a prefix 0xef4. But if that same contract is run on ETC it will throw an Invalid opcode error since the "correct" prefix for ETC would be 0xef5.

[zmitton]

Maybe we could start counting downward. I see the problem though. compiled code that would often run fine on ETC would explicitly not run on ETC if it was compiled to run on ETH.

Seems like a loss for ETC ETH compatibility

[zmitton]

Alternative would be to copy their numbers, but then you have the confusion of the contract acting like it will run, but it wont if/when it hits a (for instance) constantinople opcode

[zmitton]

Actually, I Don't think I would advocate to do it in the byzantium release. I think it makes more sense to support it once ETH does it. Especially since the next 2 upgrades for ETC: byzantium and constantinople (minus gas-metering) would be unaffected by it

[soc1c]

This should not be part of the Byzantium ECLIP. Change my mind 😆

Just write a separate ECLIP and we can add this whenever we like. I would prefer a vanilla Byzantium spec.

[meowsbits]

Closing via #10 and seeming general opinion to leave for another time.