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
- 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
- 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
- At most 100x slowdown compared to native execution
Possible side projects
- EVM Protocol implementation
Risks
These risks apply to all stages of the project:
- 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
- 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
- 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
- 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
- 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