[WIP] Arbitrum Validation Server

The Arbitrum validation server is a JSON RPC server used for executing the arbitrator or Prover VM software. It interoperates via uni-directional communication from an Arbitrum Validator (either BoLD or Legacy).

Under the hood, the golang validation server leverages FFI calls into the Arbitrator's rust functions using cgo to interact with stateful prover machines.

Machine Types

Three machine types of the arbitrator are supported:

• JIT: Just-in-time compilation, compiles WAVM interpreter instruction to machine code in real-time.
• Standard: Uses the custom interpreter for executing WAVM.
• BoLD: Wrapper over standard machine and used for interacting with BoLD validation.

JIT is the default supported option and is only used for validations.

Under the hood, these modes are mapped into two different spawner objects within the ExecutionServerAPI:

• ValidationSpawner: Used for validating a sequential collection of L2 state transitions. This is used by validators as a safety precaution before making assertions/challenges against the bridge. (i.e, you should be able to defend what you're claiming)
• ExecutionSpawner: Used during an actual dispute and is referenced for collecting machine state hashes and proofs across an execution trace.

This feature to tuple looks like:

JIT --> (JIT validation spawner, std execution spawner)
standard --> (std validation spawner, std execution spawner)

JIT

JIT is only used for validating L2 state transitions and is never referenced during an actual one step proof or dispute resolution.

The JITMachine however doesn't verify all preimage contents (e.g, 4844 blob kzg preimages) when initializing machine state and trusts the validation server to correctly compute some of them. Prestate is fed over a TCP connection from the server to a forked OS process running on the validation server instance. Using bidirectional communication, responses are read from the machine process directly to determine and yield execution results.

Config Fields

• workers: (uint) Number of concurrent workers expected to operate on the server at once. Despite being defined by the server, this value is actually managed by the client which reads it from the validation server to understand max concurrency limits respective to itself.
• cranelift: (bool) boolean used to indicate whether to use wasmer's cranelift JIT compiler. If set to false, the standard wasmer llvm backend compiler will be used.
• wasm-memory-usage-limit: Allowed memory usage for a validation run. Invariant is only enforced after successful machine execution when the machine process returns its memory consumed which is compared against the config value by the server handler.
• max-execution-time: Maximum amount of time allowed for a validation run. This is set as a lifetime deadline for the TCP connection as well as for reading/writing operations across the stream.

Standard

Unlike JIT execution which starts the machine as an individual process, standard proving sequentially executes the machine using the go server's foreign function interface calls into the arbitrator's rust code directly.

• Preimages are verified when initializaing the preimage resolver via SetPreimageResolver call

Config Fields

• workers: (uint) Number of concurrent workers expected to operate on the server at once. Despite being defined by the server, this value is actually managed by the client which reads it from the validation server to understand max concurrency limits respective to itself.
• output-path:(string) Looks like its not in use anymore
• execution: Refers to a machine caching configuration. Caching can be done to temporarily persist machines across evenly spaced points on the execution trace for fast retrieval. Supported fields:
  • cached-challenge-machines: (uint) The # of machines to store in the cache when working on some challenge.
  • initial-steps: (uint) The initial delta used between machines when first writing to cache. On first iteration, machines are evenly spaced by initial-steps which is then increased by 2^N where N is the # of iterations performed during concurrent initialization. Iterations terminate on the routine once the last seen machine doesn't have a Running status state.
• execution-runtimeout: (duration) Timeout used for pruning older execution runs when they haven't been fetched or referenced.
• redis-validation-server-config:
  • redis-url: endpoint used to reference redis instance/cluster
  • consumer-config:
    • response-entry-timeout:
    • idletime-to-autoclaim: a
  • module-roots: WASM module roots
  • stream-timeout:
  • stream-prefix:
  • workers:
  • buffer-reads:

Machine Caching

A machine cache can be leveraged to ensure faster lookups of machine states and one step proofs across a single execution trace. Caches are initialized whenever an ExecutionRun is requested by either a legacy or BoLD staker.

The ExecutionBackend used by a validator exposes a SetRange method which is called to prepare a machine cache using a (start, end) opcode position set. Upon invocation, caches are set across the execution trace for fast lookup.

TODO - illustrate sequencing

NOTES

• Execution vs validation

• ExecutionSpawner is used only during bissection and when the challenger is actively playing the fraud proof game. A CreateExecutionRun API method is invoked which returns a structured ExecutionRun to the validator client that can be referenced for reading positional execution contexts (i.e, msps, machine state hashes) at individual points of the execution trace for some L2 message. ExecutionSpawner must be used