Merge pull request #42 from ethereum/backwardsCompatibility

Add backwards compatibility page

README.md

@@ -25,6 +25,7 @@ eWASM:
 * specifies an [Ethereum environment interface](./eth_interface.md) to facilitate interaction with the Ethereum environment from an *eWASM contract*
 * specifies [metering](./metering.md) for instructions
 * and aims to restrict [non-deterministic behavior](https://github.com/WebAssembly/design/blob/master/Nondeterminism.md)
+* specifies a backwards compatible upgrade path to EVM1
 
 ### Goals of the eWASM project
 
@@ -50,6 +51,7 @@ eWASM:
 * [Rationale](./rationale.md)
 * [Ethereum environment interface](./eth_interface.md)
 * [eWASM Contract Interface](./contract_interface.md)
+* [Backwards compatibility instructions](./backwardsCompatibility.md)
 * [Original Proposal](https://github.com/ethereum/EIPs/issues/48) (EIP#48)
 * [WebAssembly design documents](https://github.com/WebAssembly/design)
 

backwardsCompatibility.md

@@ -0,0 +1,31 @@
+# Backwards Compatibility
+The current approach to achieving backwards compatibility with EVM1 is to
+support both of the instruction sets with the option to transcompiling EVM1 to 
+eWASM. This approach gives clients optionality when dealing with EVM1 code.
+A client can either implement only an eWASM VM and transcompile all of the EVM1
+code. Or a client can implement a eWASM VM and EVM1 VM and leave the old code as
+is.
+
+## Gas Prices
+In eWASM we will introduce sub-gas units so that each EVM1 opcode's
+transcompiled equivalent eWASM's gas cost is less then the original EM1 opcode's
+cost. The fee schedule for eWASM is yet to be specified.
+
+## Identification of code
+We assume there is some sort of code handler function that all clients have 
+implemented. The code handler identifies the instruction set type by whether it
+starts with WASM's magic number or not.
+
+The WASM magic number is the following byte sequence: `0x00, 0x61, 0x73, 0x6d`.
+
+## Solidity
+Support of compiling to eWASM can be accompilshed by adding a new backend to
+the solidity compile. eWASM support for Solidity is part of the MVP.
+
+## Transcompiler
+A post-MVP goal is to have the transcompiler it self become a contract by
+compiling it to eWASM. Once this is accomplished, EVM1 contracts created by 
+the CREATE op will be transcompiled to eWASM. This will also allow us to assume
+that all EVM1 code is now transcompiled eWASM code, which should be reflected
+in the state root since the has of the code is stored in the Merkle trie. Note:
+this should still allow clients to fallback to EVM1 VMs if running EVM1 code.