Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

• EIP 1679 requires approval from one of (@5chdn, @axic)

So Istanbul is last call for any "version 0" semantic changes?

@shemnon If we reached the decision to freeze version 0, then yeah, that will be the case.

What do you think about making Istanbul's version 7, motivation being that there are already 7 versions of EVM that existed on the main net (and continue to exist for clients that want to do full sync) https://github.com/ethereum/evmc/blob/9794d7c2f777545950f0185812766149b99bd019/include/evmc/evmc.h#L714

I can imagine that this could make the clients using EVMC API simpler, as they could use account's version directly to tell EVMC which EVM revision to run (with the only special case to run version 0 with EVMC_PETERSBURG)

For any other clients that similarly decouple the rules inside EVM from forks of the blockchain, the similar motivation could apply - there are already 7 rule sets for EVM, and further versions will extend this line.

cc @chfast @axic

@gumb0 Sounds like a good idea to me. :)

A small nit -- maybe we want to consider setting it to version 8 (or if we want to reserve 0 for special use case, setting it to version 9), in case we have two revisions for Istanbul (one set of changes applied directly on Petersburg VM as version 0, and another set of changes applied as a new version).

Maybe we should go the marketing route and set the version to "0x10", since this work is being done under the "Ethereum 1.x" banner. That gives us 16 updates to get serenity locked in.

I'm ok with using ordering from EVMC's EVM revision: https://github.com/ethereum/evmc/blob/master/include/evmc/evmc.h#L708-L790, so 7 for Istanbul. Or just bumping by 1, so 1 for Istanbul.

Now I think that if the plan is not to increment version with each fork, but only sometimes for really breaking changes of EVM, then each version will be active in several forks / several revisions in EVMC, and then starting with 7 will be just more confusing, it's better to start with 1.

I think the only thing that mandates a version increment at this point is adding new validation steps/rules. We can't go back and invalidate previously deployed contracts. I mean we could but we shouldn't.

Now I think that if the plan is not to increment version with each fork, but only sometimes for really breaking changes of EVM, then each version will be active in several forks / several revisions in EVMC, and then starting with 7 will be just more confusing, it's better to start with 1.

Option here is to go fully along with EVMC by skipping EVM revision number that were not connected with account version bump. E.g. 0, 7, 10, 13, ....
But I do not insist these two sequences must be connected.

@sorpaas I'd argue we should close this since account versioning wasn't included in istanbul