Behaviour on a combined EVM+ewasm chain

[axic]

This is a discussion we've had with @karalabe and @holiman.

Having a mixed chain has a lot of challenges, some of which include:

• What happens to wasm bytecode deployed on an EVM chain (which behaves as having "STOP" as its first instruction) after a hard fork enables ewasm. Suddenly the behaviour of the contract changes significantly. The bigger issue here is that it may contain code which would be rejected by ewasm validation, but it will never need to pass that validation.
• What happens to wasm bytecode deployed by EVM bytecode. It would not be validated and metered.

One possible solution to this we have discussed is to introduce a "code type" field in the account. If this field is missing it is considered to be 1 (evm). Ewasm would have a type of 2.

Contracts created by contracts always retain the code type, e.g. EVM contracts create EVM contracts, ewasm contracts create ewasm contracts.

This also simplifies the rules about selecting the execution engine in a transaction.

[lrettig]

One possible solution to this we have discussed is to introduce a "code type" field in the account

In addition to being more explicit, which I believe is always good, this also opens two other interesting possibilities:

• Supporting multiple EVM bytecode versions
• Supporting other VM/bytecode formats in future. In this way a "code type" field is more future proof.

[lrettig]

Contracts created by contracts always retain the code type, e.g. EVM contracts create EVM contracts, ewasm contracts create ewasm contracts.

Other than sheer simplicity, what's the argument in favor of forbidding one code type from creating code of another code type? This could be accomplished with multiple CREATE opcodes/methods (e.g., CREATEEVM, CREATEEWASM, etc.), with an arg to CREATE, or possibly CREATE could auto-detect the code type the way hera does today.

[axic]

The alternative is following up on #39 and and having a "bytecode version" field in front of the code in every single case, but that is still affected by problem 1) above.

Other than sheer simplicity, what's the argument in favor of forbidding one code type from creating code of another code type?

See problem statement 2) up there. Introducing bunch of new opcodes to EVM sounds like a bad idea.

[lrettig]

Linking a related eth-magicians forum thread: https://ethereum-magicians.org/t/evm-instruction-set-versioning/2286