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.

Sign up for GitHub

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

Jump to bottom

added backwards compatibility page #20

Merged
merged 1 commit into from
Aug 3, 2016
Merged

added backwards compatibility page #20

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
29 changes: 29 additions & 0 deletions BackwardsCompatibility.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
# Backward 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
EVM2. This approach gives clients optionality when dealing with EVM1 code.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we stick to eWASM instead of EVM2?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

A client can either implement only a WASM VM and transcompile all of the EVM1
Copy link
Member

@axic axic Aug 3, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WASM VM

eWASM VM

code. Or a client can implement a wasm VM and EVM1 VM and leave the old code as
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wasm VM

eWASM VM

is.

## Gas Prices
In eWASM we will introduce sub-gas units so that each EVM1 opcode's
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also think about the possibilty to add a second, unrelated unit of gas.
Working out realistic gas costs for the opcodes already proved extremely difficult for the EVM. Especially when the goal of eWASM is to remove all precompiles, this will not become easier and we will drag this problem along.
The introduction of different gas "components" would also provide an avenue for future extendability, perhaps with the introduction of a gas component that is used for storage rent or differently scaling gas for memory usage and computation costs.

When we have the serenity abstraction, we could have a gas opcode that takes an integer argument, where gas(0) is the gas used by all EVM1 contracts and gas(1) is the gas used by eWASM contracts. The transaction can then apply different scaling factors (gas costs) for those components when paying the validator.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah If we can provided a way to do differential metering without added to much complexity then I think that would be ideal.

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 (0x6d736100) or not.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The magic number is in LSB order, therefore it is [00, 61, 73, 6d] on the wire.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This magic number results in a successful execution when interpreted as EVM code. Would it be better to start with an invalid EVM opcode?

Copy link
Member

@axic axic Aug 4, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We were talking about that in #2.

To do an invalid jump and force a "throw" we would need to add a prefix (jump) and suffix (jumpdest at the end of the code), right? Is there any way to do that as a prefix only?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An invalid opcode would suffice.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case it would be nice to officially dedicate an opcode as invalid. I propose to go with 0xEF. That seems to be the least unlikely to be populated :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This magic number results in a successful execution when interpreted as EVM code.

If VM see it as [00, 61, 73, 6d] then we should be fine. Since 00 is stop. Although appended with 0xEF would be fine too if it was offically dedicate as invalid.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chriseth @wanderer this discussion is moved to #39


## 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 wasm. 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.