Try   HackMD

ZK WASM Roadmap Stages

Author: akashin
Created on: September 14, 2023
Status: Final


Stage 1

Timeline: September 2023 - November 2023

At this stage we focus on proving individual simple WASM programs.

Supported workloads

  • WASM MVP Spec tests and instruction set
    • We'll skip floating point operations if we can't find a simple software implementation
    • We will support bulk memory operations (memory.fill and memory.copy), but initially they can be very inefficient

Changes to ZK processor

  • Switch from 256 to 64 bit registers
  • Have 16 general-purpose registers
  • Still based on PIL1

Performance goals

  • At most 1000x slowdown compared to native execution

Possible side projects

  • Compressing Merkle proofs for stateless validation

Stage 2

Timeline: November 2023 - December 2023

At this stage we focus on proving one complex program - WASM interpreter.

This will allow us to have a single circuit that can prove any WASM program or even a batch of different WASM programs.

Supported workloads

  • WASM interpreter - WASMI (subject to change)

Changes to ZK processor

  • Registers, memory and instructions optimized for WASM
  • Likely based on PIL2
  • There will be changes to the prover/executor with this new processor

Performance goals

  • At most 200x slowdown compared to native execution

Possible side projects

  • EVM interpreter - SputnikVM

Stage 3

Timeline: January 2024 - March 2024

At this stage we focus on proving one complex library - NEAR protocol.

Supported workloads

  • NEAR Protocol implementation
    • We will likely need a no_std version of it

Changes to ZK processor

  • Support for NEAR host functions
  • Support for NEAR state storage

Performance goals

  • At most 100x slowdown compared to native execution

Possible side projects

  • EVM Protocol implementation

Risks

These risks apply to all stages of the project:

  1. Performance of proving might not be good enough
    • We will start evaluating performance early and build projections for the future
    • We will understand ZK side enough to be realistic about future performance improvements
  2. We might have too many bugs because correctly implementing WASM semantics is hard
    • We will make sure to have a good test coverage and use WASM Spec test as a part of CI
  3. Some workloads might be impossible to support with current proving technology (e.g. large state, long computations)
    • We will identify max size of state and length of computation for Stage 1 and Stage 2 early and communicate it to ZK VM team
  4. We might not be productive with Cranelift codebase
    • We will invest in aligning our solution with abstractions used by other Cranelift backends
    • We will build up a relationship with Cranelift dev team to get necessary support
  5. ZK ASM processor might turn out to be not well suited for WASM execution
    • We will consult with ZK specialists who are familiar with building ZK VMs to understand what is needed for ZK VM to be a good compilation target