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