design
design copied to clipboard
ewasm
Use invalid opcode as part of the eWASM magic
Following the discussion: https://github.com/ethereum/evm2.0-design/pull/20#discussion_r73419436
@chriseth since you mentioned the requirement for this, can you please explain why we should have it?
The idea is that multiple versions of evm bytecode can be introduced with limited backwards-compatibility breaks. We can at least be rather sure that no useful existing contract can have the same bytecode (prefix) as an ewasm contract.
We can at least be rather sure that no useful existing contract can have the same bytecode (prefix) as an ewasm contract.
Currently all wasm binaries a prefixed with 0x00, which is stop. Wouldn't that eliminate all useful contracts?
This aims for a general standard to select the proper VM for a given bytecode, without having to add metadata to an account. Since we do not have a VM identifier for EVM1, anything is valid EVM1. In order to avoid cases where an existing contract written for EVM1 is mistaken for eWASM bytecode which would change its semantics, I would propose to take a first byte that cannot be the start of a contract that is in use, and I think 0xef is more likely to fulfil that purpose than 0x00.
right, so if we go that route we probably should drop the wasm magic number 0x00, 0x61, 0x73, 0x6d and replace it with just a single 0xfe
No, I still think that a kind of version number of VM identifier should follow the 0xfe because that allows for upgrading the VM much more easily.
0x00, 0x61, 0x73, 0x6d ("0asm") is wasm identifier, it is followed the version number (0x01). So if we replaced the identifier then we would still have the version number to go off of for future upgrades
I would argue this is not needed, because wasm cannot be introduced without the client knowing about it, and if it does, it can easily detect the "wasm magic" as a pattern.
In theory it would be nice for a client to be able to implement some, but not all, VMs and to be able to detect which VM a particular piece of contract bytecode targets, so that it can choose to execute that contract or not -- this wouldn't make sense for main chain but it could make sense for a private network, or maybe for a hypothetical world where different shards run different VMs. It would be nice to maintain optionality.
