W3.io Logo
Menu

Virtual Machine

Industry evolution and W3's implementation (WASM now, ZK-optimized later).

Industry Examples

How existing blockchains chose VMs.

Ξ

Ethereum

  • VM: EVM (custom stack machine)
  • ISA: ~140 opcodes (ADD, SLOAD, CALL)
  • Language: Solidity, Vyper
  • Design: 256-bit words, gas metering, precompiles
◎

Solana

  • VM: eBPF (Linux kernel VM)

  • ISA: eBPF instructions

  • Language: Rust (Anchor framework)

  • Design: JIT compilation, parallel execution

⬢

Polkadot

  • VM: WASM runtime
  • ISA: WebAssembly
  • Language: Rust (ink! framework)
  • Design: Modular, upgradeable runtimes

Industry Evolution

Three generations of blockchain VMs.

Custom VMs (2009-2015)

Early chains invented custom VMs. Bitcoin: Script (minimal, non-Turing complete). Ethereum: EVM (256-bit stack machine, Turing complete).

Examples: Bitcoin Script (2009), Ethereum EVM (2015)

Reusing Existing VMs (2018-present)

Reusing Existing VMs (2018-present)

← You are here

Chains realized VMs are solved problems. Why reinvent? Adopt proven tech with mature tooling.

WASM: Polkadot, NEAR, Dfinity. Web-standard VM, mature tooling.

eBPF: Solana. Linux kernel VM, high performance.

EVM (again): zkSync, Optimism, Arbitrum. Compatibility over innovation.

ZK-Optimized VMs (emerging)

New bottleneck: interoperability and privacy. Zero-knowledge proofs enable both, but proving execution is expensive. VMs matter because some instruction sets are far cheaper to prove than others.

Why ZK changes everything:

  • Interoperability: Prove on Ethereum that a workflow executed on W3 → control ETH smart contracts from workflows.

  • L2 scalability: Post succinct proofs to Ethereum instead of running full consensus → inherit ETH security, subsidize costs.

  • Privacy: Prove workflow execution without revealing parameters or intermediate state.

Problem: Not all VMs are ZK-friendly

Generating a ZK proof means converting VM execution into arithmetic circuits. Complex instructions = massive circuits = slow proving, high memory costs.

EVM example: 256-bit word operations explode into thousands of field operations. Proving 1 second of EVM execution can take minutes and gigabytes of RAM.

RISC-V: Simple, orthogonal ISA. 32/64-bit words (not 256-bit). Small instruction set. Proving costs 10-100x cheaper than EVM. Ethereum considering it as replacement.

Upgraded WASM?: Could add ZK-friendly extensions, but fundamentally designed for native execution, not proving.

Something else?: Winning standard hasn't emerged. Watch for Ethereum's move.

Our Approach

W3's VM strategy.

Start Practical, Migrate When Standards Emerge

🕸️

Phase 1: WASM

Battle-tested runtimes (wasmer, wasmtime), rich ecosystem.

4-6 weeks to POC

?

Phase 2: ZK-Optimized VM

Migrate when industry converges. Could be RISC-V, upgraded WASM, or something else.

When ecosystem signals clear

Key advantage: Design for portability

Keep VM layer clean with well-structured bytecode and abstracted host functions. Migrating VMs is straightforward if you don't marry WASM specifics.

Pragmatic strategy: Start with L1 + WASM, ship product, build ecosystem. Upgrade to ZK-optimized execution (possibly L2) when business justifies complexity and cost.

Deployment Model: Source vs Bytecode

Bytecode Only: Compile locally, deploy bytecode. Private but opaque.

Optional Source (Recommended):

Deploy bytecode, optionally verify source (like Etherscan).

Reality: Bytecode privacy is weak (easy to reverse-engineer). For real IP protection: encrypt parameters in TEE, put proprietary logic in bytecode-only Smart Actions.