aurora-is-near / aurora-engine

⚙️ Aurora Engine implements an Ethereum Virtual Machine (EVM) on the NEAR Protocol.
https://doc.aurora.dev/develop/compat/evm
325 stars 78 forks source link

Feat(standalone): logic for parsing TransactionKind from raw Near data #810

Closed birchmd closed 1 year ago

birchmd commented 1 year ago

Description

This is the first in a series of PRs that is meant to split up #705 . The idea is to merge the changes which are made in that PR in logical chunks until eventually the whole hashchain implementation is in. Doing the work in smaller pieces will both make it easier to review and prevent us from needing to maintain large, long-lived feature branches.

This first PR pulls in the transaction transaction parsing logic from borealis-engine-lib into this repo (in a future PR we will remove the duplicated code from borealis-engine-lib). The logic is used here to simplify how transactions are handled in tests because all transactions can automatically be passed to both the Near runtime (processed by the Engine as Wasm) and the standalone engine. In particular we remove the large if statement that was starting to get unwieldy.

This work is important both because it makes future tests easier to write and because it synchronizes the standalone and wasm engine instances in our tests (this latter point is a prerequisite for properly testing the hashchain).

Some notes about the PR:

  1. I renamed the constant ORIGIN to DEFAULT_AURORA_ACCOUNT_ID because I felt the latter is a more descriptive name for what the constant represents.
  2. The standalone engine is now present in AuroraRunner by default to make out testing more robust (for example tests will now automatically fail if a new state-mutating method is added to the Engine's lib.rs without also being added to the standalone implementation). This means there are a few places were I need to explicitly remove the standalone instance where AuroraRunner is used as something other than an Engine instance (modexp and xcc tests).
  3. Some tests use view calls to inspect the Engine state and make assertions. These calls are not present in the standalone because it only cares about transactions that mutate the state. To make view calls in AuroraRunner it is now required to call .one_shot() before the calls. This essentially tells the testing framework that you are making a view call so no state modifications will be made and therefore we can ignore the standalone.