ethereumjs-ovm comparison

[cgewecke]

This PR is a diff vs. ethereumjs v4. Most recent commit here is from March 6, 2021.

As things stand, to upgrade their js-vm to V5 & Berlin, Optimism would have to maintain and publish from a fork of the ethereumjs-monorepo.

This entails significant maintenance overhead.

ethereum-js could make itself more configurable and reduce complexity for OVM if

• ethereumjs VM

  • adds init initialization hook, initialization options
  • makes EVM a VM option in some form
  • makes logging configurable?

• Optimism could extend the StateManager EVM and EEI classes

class OptimisticStateManager extends DefaultStateManager

class OVM extends EVM
  class OEEI extends EEI // OVM instantiates OEEI

A new VM might look like

import VM from "ethereumjs/vm";
import { OptimisticStateManager, OVM } from "@eth-optimism/something";

const extension: {
    init: () => // this is invoked in addition to standard init?
    evm: OVM // this would always be passed as an option to `runCode` and `runCall` and instantiated there. 
    something: ...,  // stuff that gets attached to the vm object and can be accessed via `.extension`
    ...    
}

const vm = new VM({
  ...,
  stateManager: new OptimisticStateManager(...),
  extension
});

[cgewecke]

Could toOvmMessage be a static helper in evm.ts which took the original message as an arg?

This would mean there was no need to extend the message class.

[cgewecke]

Hmmm....not sure what to do here with runTx.

[cgewecke]

What is this?

[cgewecke]

👀