-
Notifications
You must be signed in to change notification settings - Fork 81
Add recent op codes #37
Comments
Would be great to see this! The 5 opcodes missing in reference to the yellow paper are: |
@eddyashton did you have any ideas around REVERT? As a patricia merkle tree is not used here for committing and reverting, perhaps a changelog per "context" that stores the initial state of each account and KV "touched" would work better. In the case of a revert, this changelog would hold the minimum information required to reverse all state changes. |
@jafri I think the right way to handle
The latter point deserves some futher explanation: As a sketch of a similar setup in the style of
A less intrusive way to get the same result is just to copy the global state before execution - then one holds the original state and the other can be executed on, if execution fails the latter is discarded. This would be more difficult if we tracked gas, in which case all gas changes would be permanent/instantly applied, while the corresponding state changes may be discarded. Luckily we don't track gas at all in eEVM, so we don't have to worry about it. Hope that helps, happy to answer any other questions you have. |
@eddyashton that would work, will need local changes for Accounts and local changes for Storage |
Since the eEVM was first implemented, additional op codes have been added to the EVM spec (notably
RETURNDATASIZE
,RETURNDATACOPY
, andREVERT
). Currently contracts must be compiled explicitly targeting the Homestead spec, or they will produce unaccepted op codes. Adding support for these would make it possible to run more recent real-world example contracts, and to validate the eEVM against current external test sets.The text was updated successfully, but these errors were encountered: