added backwards compatibility page #20
Conversation
| # 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. |
There was a problem hiding this comment.
Maybe we stick to eWASM instead of EVM2?
| is. | ||
|
|
||
| ## Gas Prices | ||
| In eWASM we will introduce sub-gas units so that each EVM1 opcode's |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
yeah If we can provided a way to do differential metering without added to much complexity then I think that would be ideal.
This is the initail stab at documenting backwards compatibility