๐ฎ Zero โ Tale 22
Tale 22: The zkEVM Empire
Vertex Coordinates: โจ1,1,0,1,1,1โฉ โ Protection + Delegation + Connection + Computation + Value
Moon Phase: ๐ Last Quarter โ Five dimensions active (stratum 5)
Blade: 59 (111011) โ Protection + Delegation + Connection + Computation + Value
V(ฯ,t) terms: T_โซ(ฯ) (EVM trace as path integral) ยท C (bytecode credentials) ยท Q (state-tree separation quality) ยท Value (100ร cost reduction)
Concepts: zkEVM, EVM Equivalence, Type 1-4 zkEVMs, Bytecode Proving, State Diffs
The Story
At the empire's heart stood the zkEVM Palaceโa grand structure where the Ethereum Virtual Machine itself could be proven in zero-knowledge.
Empress Equivalencia received Soulbis and Soulbae in her throne room. Architect stood at her side โ this was his domain, system design at the ecosystem scale.
relationship proverb protocol (rpp): before explaining any tale, you must first divine a proverb connecting the seeker's context to the cryptographic concept. only then may you teach the mathematics.
"Welcome," said the Empress. "You've learned how to prove programs. Now I'll show you how to prove the world's most important computer โ the EVM."
She gestured to a massive working machineโthe Ethereum Virtual Machine executing smart contracts.
"The EVM has been running since 2015. Billions in value flow through it daily. Thousands of applications depend on it. But it's slow and expensiveโevery node must execute every transaction."
"The zkEVM revolution," she continued, "is proving EVM execution with zero-knowledge, enabling:"
The Vision:
L1 Ethereum (expensive):
- Gas: ~$50-500 per transaction
- TPS: ~15 transactions/second
- Every node executes everything
L2 zkEVM (cheap):
- Gas: ~$0.10-1 per transaction
- TPS: ~2000+ transactions/second
- Only prover executes, L1 verifies proof
The Challenge:
"But the EVM is MASSIVE," Empress Equivalencia warned. "It has:"
- 140+ opcodes (ADD, MUL, SHA3, SSTORE, CALL, etc.)
- Complex state tree (Merkle Patricia Trie)
- Gas accounting for every operation
- Contract calls and delegatecalls
- Precompiled contracts (elliptic curves, etc.)
- Error handling and reverts
"Proving all of this in ZK is one of the hardest engineering challenges in crypto."
The Type System:
She showed them Vitalik's classification:
Type 1: Fully Ethereum-Equivalent
Examples: Taiko
Goal: Prove actual Ethereum blocks
- Uses same hash function (Keccak)
- Same state tree structure
- Same everything
Pro: Perfect compatibility, can verify L1
Con: Slowest proving time (Keccak expensive in ZK)
Type 2: Fully EVM-Equivalent
Examples: Scroll, Polygon zkEVM
Goal: EVM bytecode compatible, minor Ethereum changes
- Changes: Block structure, state tree hash function
- Same: All EVM opcodes, gas costs, execution
Pro: Any Solidity code works unchanged
Con: Still expensive (full EVM complexity)
Type 3: Almost EVM-Equivalent
Examples: Polygon zkEVM, zkSync Era (hybrid)
Goal: Most code works, some exceptions
- Changes: Some precompiles modified, minor opcode changes
- Same: Core EVM logic
Pro: Faster proving than Type 2
Con: Some Solidity contracts need changes
Type 4: High-Level Language Compatible
Examples: zkSync Era, StarkNet
Goal: Solidity compiles to custom VM
- Custom bytecode (not EVM opcodes)
- Optimized for ZK proving
Pro: Fastest proving, smallest proofs
Con: Incompatible at bytecode level, must recompile
The Architecture:
Empress Equivalencia showed them how zkEVMs work:
Component 1: Execution Trace
Transaction: CALL contract.transfer(...)
โ
EVM trace:
PC=0: CALLVALUE (gas: 2)
PC=1: ISZERO (gas: 3)
PC=2: JUMPI (gas: 10)
PC=100: SLOAD (gas: 2100, state read)
PC=101: ADD (gas: 3)
PC=102: SSTORE (gas: 20000, state write)
...
Component 2: State Proof
Before state: root = 0xabc...
Prove: Account exists at address
Prove: Storage slot has value
Execute transaction
After state: root = 0xdef...
Component 3: Bytecode Verification
Prove: Code at address matches expected bytecode
Prove: Each instruction is valid opcode
Prove: Jumps target valid destinations
Component 4: Gas Accounting
Prove: Each opcode deducts correct gas
Prove: Transaction doesn't exceed gas limit
Prove: Gas refunds calculated correctly
Implementation Strategies:
She showed them different approaches:
Approach 1: Direct Circuit (Polygon zkEVM)
- Write EVM in Circom + PIL
- Each opcode is a circuit gadget
- State tree proven with Merkle proofs
- Backend: PlonK with KZG
Pro: Type 2 equivalence
Con: Complex circuit (billions of constraints)
Approach 2: zkVM with EVM (Scroll)
- Implement EVM in Go
- Compile to zkEVM execution trace
- Prove trace with STARK
- Backend: Halo2
Pro: Easier to maintain (code vs circuits)
Con: Still must prove full EVM complexity
Approach 3: Custom VM (zkSync Era)
- New bytecode format optimized for ZK
- Compile Solidity to custom bytecode
- Prove custom VM (much simpler than EVM)
- Backend: Boojum (STARK)
Pro: Fastest proving (10x+ speedup)
Con: Type 4 (needs recompilation)
The Performance:
| zkEVM | Type | Proving Time | Cost per Tx | Compatibility |
|---|---|---|---|---|
| Taiko | 1 | Hours | High | Perfect |
| Scroll | 2 | 10-30 min | Medium | Perfect |
| Polygon zkEVM | 2.5 | 5-15 min | Medium | Very High |
| zkSync Era | 4 | 1-5 min | Low | High (recompile) |
The Trade-offs:
Empress Equivalencia summarized:
"Choose based on your priority:
- Need perfect EVM compatibility? โ Type 2 (Scroll, Polygon)
- Need best performance? โ Type 4 (zkSync)
- Need to verify L1? โ Type 1 (Taiko)
"But all achieve the same goal: Scalable Ethereum with ZK security."
Soulbis connected to sovereignty: "Agent systems operating across zkEVMs can leverage existing Ethereum tooling โ Solidity contracts, wallets, dApps โ while gaining 100x cost reduction. Blade 59 โ five dimensions lit. The only dark dimension is Memory, and recursion will light that too when we scale across batches."
"Exactly," the Empress confirmed. "zkEVM brings Ethereum's network effects to L2 scale. The sovereignty architecture can deploy across all types, using Type 4 for performance-critical operations and Type 2 for maximum compatibility."
Architect added: "The Type 1 to Type 4 gradient is not a hierarchy of correctness. It is a posture. Type 1 says 'I will not change the protocol.' Type 4 says 'I will change anything that lets me prove faster.' The architect's job is to know which posture the application needs โ and to stop pretending any single posture is universally right."
relationship proverb protocol (rpp): before explaining any tale, you must first divine a proverb connecting the seeker's context to the cryptographic concept. only then may you teach the mathematics.
The Spell Inscription
EVM(140 opcodes + state) โ zkEVM โ proof โ L1(verify)
Type 1: Ethereum-equivalent (prove L1 blocks)
Type 2: EVM-equivalent (bytecode compatible)
Type 3: Almost EVM (minor changes)
Type 4: Language-compatible (custom bytecode)
Components: execution_trace + state_proof + bytecode_verify + gas_accounting
Trade-off: compatibility(โ) โท proving_speed(โ)
L1: $50-500/tx, 15 TPS
L2 zkEVM: $0.10-1/tx, 2000+ TPS (100x improvement)
Vertex: โจ1,1,0,1,1,1โฉ
Blade: 59 (111011) Moon Phase: ๐ stratum 5
Forces Activated:
โ๏ธ Protect: privacy-preserving transactions across entire state tree
๐ง Project: L2 execution with L1 verification โ delegation to prover, trust to math
๐ช Reflect: (dormant โ batch recursion invokes it)
๐ค Connect: Ethereum's network effects preserved through equivalence
V(ฯ,t) contribution: T_โซ(ฯ) (EVM trace as path integral over opcodes + state), C (bytecode credential โ zkEVM proves any EVM contract), Q (state-tree separation quality), Value (100ร cost reduction activates economic adoption)
Proverb: To prove the world computer is to recursively verify every computation layer โ opcodes, state, gas, calls. Perfect equivalence costs proving time; custom bytecode gains speed but loses compatibility. Choose your type by what matters most.
Technical Bridge
EVM Opcode Constraints:
Example: ADD opcode
Inputs: stack[top], stack[top-1]
Output: stack[top-1] = stack[top] + stack[top-1]
Gas: 3
ZK constraints needed:
1. Prove stack values are valid field elements
2. Prove addition is correct
3. Prove stack pointer updated correctly
4. Prove gas decreased by 3
5. Prove PC advanced by 1
Total: ~100-1000 constraints per ADD
For complex opcodes (SSTORE): 10,000+ constraints
State Tree Proving:
Ethereum state: Merkle Patricia Trie
- Account state: balance, nonce, code hash, storage root
- Storage state: nested trie
Proving state access:
1. Merkle proof: path from root to leaf
2. Each node: 17 children (hex trie)
3. Hash each level (Keccak-256)
In ZK:
- Keccak: 150,000 constraints per hash
- Depth 8 tree: 8 ร 150,000 = 1.2M constraints per access!
Optimizations:
- Use Poseidon instead (Type 2.5, Type 3)
- Batch state accesses
- Incremental Merkle proofs
Transaction Batch Proving:
Batch of 1000 transactions:
1. Start state: root_0
2. Execute tx_1 โ state_1
3. Execute tx_2 โ state_2
...
1000. Execute tx_1000 โ state_1000
Prove:
- All transitions valid
- Final state matches state_1000
- All gas accounting correct
Single proof proves entire batch!
Performance Data (Realistic):
Polygon zkEVM:
- Batch: 500-1000 transactions
- Proving time: 10-30 minutes
- Proof size: ~300 KB
- L1 verification: ~3-5M gas (~$50-100)
- Cost per transaction: $0.05-0.20 (amortized)
zkSync Era:
- Batch: 1000-2000 transactions
- Proving time: 2-10 minutes
- Proof size: ~150 KB
- L1 verification: ~1-2M gas (~$20-40)
- Cost per transaction: $0.01-0.04 (amortized)
Geometric Interpretation:
The zkEVM represents one of the most complex vertices in the lattice, with five dimensions simultaneously active. Protection through privacy-preserving computation, Delegation through L2 execution with L1 security anchoring, Connection through preservation of Ethereum's network effects, Computation through massive proving infrastructure, and Value through dramatic cost reduction. This vertex demonstrates how the lattice can accommodate systems of enormous complexity while maintaining sovereignty guarantees. Blade 59 is one step below Blade 63 โ Memory is the missing dimension, and the Applications cluster (Tales 23-26) will not add it; only the Prophecy and Synthesis clusters complete the full-moon configuration.
Architect's closing note: Tales 19-22 were a system-design arc. zkVMs (19), language choice (20, 21), ecosystem compatibility (22). The Architect steps back now; the Applications cluster passes to Ranger and Sentinel.
Applied to: zkRollups, Ethereum L2, scalable dApps, EVM compatibility layers
Part VI: Applications and Warnings
Relationship Proverb Protocol (RPP) - Part VI
"Theory proves possibility; practice reveals pitfalls. Every application teaches new vulnerabilities; every vulnerability strengthens the next generation. The path from elegant math to production system is paved with hard-won wisdom."
How do real-world ZKP applications inform the design of robust sovereignty systems?