-
Notifications
You must be signed in to change notification settings - Fork 126
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
added backwards compatibility page #20
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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. | ||
A client can either implement only a WASM VM and transcompile all of the EVM1 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
eWASM VM |
||
code. Or a client can implement a wasm VM and EVM1 VM and leave the old code as | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
eWASM VM |
||
is. | ||
|
||
## Gas Prices | ||
In eWASM we will introduce sub-gas units so that each EVM1 opcode's | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. When we have the serenity abstraction, we could have a gas opcode that takes an integer argument, where There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The magic number is in LSB order, therefore it is There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 ( There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. An invalid opcode would suffice. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
|
||
## 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done