Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add backwards compatibility page #42

Merged
merged 4 commits into from
Aug 15, 2016
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -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)

Expand Down
31 changes: 31 additions & 0 deletions backwardsCompatibility.md
Original file line number Diff line number Diff line change
@@ -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.