zk, zkVM, zkEVM의 현재와 미래

Ethereum L1 zkEVM, 범용 zkVM, Native Rollup을 중심으로

2026년 7월 기술 문서 통합판

TL;DR

블록체인 업계에서 ZK라고 부르는 기술은 실제로는 privacy를 사용하지 않는 validity proof인 경우가 많다.
현대 proof system은 SNARK 대 STARK라는 단순한 이분법으로 설명하기 어렵다. 실제 구현은 arithmetization, polynomial commitment scheme, lookup, recursion, field, hash function과 hardware backend를 조합한 modular stack이다.
zkVM은 application별 circuit을 제거하는 것이 아니라, 복잡성을 재사용 가능한 VM circuit과 proving runtime으로 이동시킨다.
General-purpose zkVM과 zkEVM은 경쟁 관계에서 기반 기술과 application 관계로 바뀌었다. 최신 zkEVM은 대체로 범용 zkVM 위에서 Ethereum State Transition Function을 guest program으로 실행하는 구조다.
Ethereum L1 zkEVM의 real-time proving 목표는 target hardware 기준으로 이미 상당 부분 달성됐다고 Ethereum Foundation은 평가한다. 현재 더 큰 과제는 cryptographic security, formal verification, client integration, multiproof diversity와 prover economics다.
EIP-8025의 Optional Execution Proofs는 Hegotá 후보로 제안됐지만, 2026년 7월 18일 현재 공식 EIP 상태는 Stagnant다. Ethereum mainnet에 채택된 기능으로 보면 안 된다.
Native rollup을 제안하는 EIP-8079도 Draft이며 핵심 specification과 security consideration에 다수의 TBD가 남아 있다.
최종적으로 general zkVM은 zkEVM killer가 아니라, zkEVM과 verifiable computation을 구현하는 공통 proving substrate가 되고 있다.

1. 2022년의 전망은 어디까지 맞았는가

2022년 원문은 다음 두 가지를 핵심 미래로 제시했다.

Native zkEVM is the future of blockchain.

General zkVM is the future of Web3.

그리고 WASM이나 RISC-V 기반 범용 zkVM이 발전하면 zkEVM을 대체할 수 있다고 전망했다. 또한 zkVM을 mainstream ISA, EVM ISA, ZK-optimized ISA로 분류하고, zkEVM을 EVM compatibility와 proof friendliness를 함께 제공하는 환경으로 설명했다.

방향 자체는 상당 부분 맞았다.

범용 zkVM은 실제로 Rust, C, C++ 등의 일반 언어와 RISC-V compiler toolchain을 사용하는 방향으로 발전했고, Ethereum은 L1 block execution 자체를 zkVM으로 증명하는 로드맵을 공식적으로 추진하고 있다. 다만 결과는 zkVM 대 zkEVM의 승자 독식 구도가 아니다.

현재의 구조는 다음과 같다.

General-purpose zkVM
        +
Ethereum STF guest program
        =
Ethereum-compatible zkEVM

Ethereum Foundation의 정의에서도 zkEVM은 일반적으로 zkVM을 선택하고 Ethereum State Transition Function 구현을 guest program으로 설정하는 방식으로 구성된다.

따라서 2022년의 결론은 다음처럼 수정하는 편이 정확하다.

General zkVM is not a zkEVM killer. It is becoming the execution-proof substrate on which zkEVMs are built.

2. 먼저 ZK와 validity proof를 구분해야 한다

엄밀한 zero-knowledge proof는 prover가 어떤 statement가 참이라는 사실을 증명하면서도 witness 또는 private input에 관한 추가 정보를 verifier에게 공개하지 않는 proof다.

하지만 blockchain scaling에서 ZK라는 용어는 다음 속성을 포괄하는 마케팅 또는 기술 약어로 사용되는 경우가 많다.

Computational integrity
Succinct verification
Proof of correct execution
Validity proof
Optional zero-knowledge privacy

즉, zk-rollup이나 zkVM이 사용됐다는 사실만으로 transaction, state 또는 input이 비공개가 되지는 않는다.

Privacy를 구현하려면 별도로 다음과 같은 요소가 필요하다.

Hiding commitment
Private input handling
Nullifier
Encrypted state 또는 private state model
Zero-knowledge masking
Private data availability 또는 selective disclosure

STARK 역시 기본적으로 자동으로 zero knowledge가 되는 것은 아니다. 별도의 randomization과 masking 기법을 추가해야 zero-knowledge property를 얻는다.

따라서 scaling 문맥에서는 다음 표현이 더 정확하다.

zkVM은 프로그램 실행의 정확성을 succinct proof로 증명하는 virtual machine이며, privacy는 선택적으로 구성되는 별도 속성이다.

3. SNARK 대 STARK만으로는 현대 proof system을 설명할 수 없다

2022년 원문은 proof system을 SNARK와 STARK라는 두 분류로 설명했다. 당시 입문 문서에서는 일반적인 접근이었지만, 현재 구현을 분석하기에는 지나치게 단순하다.

SNARK와 STARK는 완전히 배타적인 implementation architecture가 아니다.

SNARK는 succinct, non-interactive argument라는 넓은 속성의 집합이다.
STARK는 transparent setup과 scalable proving을 지향하는 proof construction 계열이다.
FRI를 polynomial commitment로 사용하는 SNARK도 존재한다.
STARK proof를 작은 SNARK로 recursive wrapping할 수도 있다.
하나의 시스템에서 여러 proof protocol과 commitment scheme을 결합할 수 있다.

현대 proof stack은 다음과 같이 분해해서 봐야 한다.

Layer	주요 역할과 선택지
Computation model	Circuit, VM, state transition
Arithmetization	R1CS, AIR, PLONKish, multilinear constraints
Interactive oracle protocol	STARK, PLONK 계열, sumcheck
Polynomial commitment scheme	KZG, IPA, FRI, WHIR 계열
Lookup argument	Instruction, range, cryptographic primitive lookup
Fiat–Shamir transform	Interactive protocol의 non-interactive 변환
Recursion	Segment aggregation, proof composition, compression
Final wrapper	On-chain verifier에 적합한 proof 생성
Field and hash	Prime field, small field, binary field, Poseidon, Keccak 등
Backend	CPU, GPU, FPGA, ASIC

Plonky3만 해도 univariate STARK, multivariate STARK와 PLONK 계열을 지원하면서 FRI 기반 PCS, tensor PCS, 여러 field와 hash function을 조합할 수 있는 toolkit으로 설계돼 있다.

따라서 다음과 같은 일반화는 부정확하다.

STARK는 항상 SNARK보다 빠르다.
SNARK는 항상 trusted setup이 필요하다.
STARK는 항상 gas cost가 낮다.
Proof size는 proof system의 이름만 보면 알 수 있다.
Post-quantum security는 STARK라는 이름만으로 자동 보장된다.

실제 성능과 보안은 arithmetization, PCS, field size, query count, recursion topology, hash security, verifier environment와 hardware parallelism의 조합으로 결정된다.

4. zkVM의 전체 실행 구조

zkVM은 일반 virtual machine과 유사하게 program을 실행하지만, 실행 결과와 함께 execution correctness를 증명하는 proof를 생성한다.

Source Program
      │
      ▼
Compiler / Toolchain
      │
      ▼
Guest Binary
      │
      ▼
zkVM Executor
      │
      ├── Public Input
      ├── Private Input
      └── Execution Trace / Witness
                  │
                  ▼
        Arithmetization / Constraints
                  │
                  ▼
          Proving System Backend
                  │
                  ▼
          Recursive Aggregation
                  │
                  ▼
      Proof + Public Output + Program ID
                  │
                  ▼
               Verifier

Application developer가 직접 작성하는 것은 주로 guest program이고, zkVM 구현자는 다음 계층을 담당한다.

ISA semantics
CPU 또는 instruction constraints
Memory consistency
Control-flow constraints
Syscall and precompile interface
Witness generation
Proof generation
Recursion and aggregation
Verification key management
On-chain verifier

따라서 zkVM이 circuit engineering을 없앴다고 보는 것은 잘못이다.

zkVM은 circuit complexity를 제거한 것이 아니라 application layer에서 reusable infrastructure layer로 이동시킨다.

5. RISC-V가 zkVM의 중심 ISA가 된 이유

현재 모든 zkVM이 RISC-V를 사용하는 것은 아니다. Ethproofs에 통합된 zkVM만 보더라도 RV32IM, RV64IM, RV64IMA와 MIPS 등 여러 ISA가 사용된다.

그럼에도 Ethereum L1 zkEVM과 general-purpose zkVM에서 RISC-V가 공통 기반으로 자리 잡은 이유는 명확하다.

Open ISA

RISC-V는 공개되고 안정적인 Instruction Set Architecture다. Proprietary ISA와 달리 circuit implementation, compiler target과 compliance tooling을 독립적으로 구현할 수 있다.

Mature compiler ecosystem

Rust, C, C++ 등 기존 언어를 LLVM 기반 RISC-V target으로 compile할 수 있다. SP1은 RISC-V로 compile 가능한 Rust, C와 C++ program을 증명할 수 있도록 제공한다.

Simple and modular semantics

RISC-V는 상대적으로 작은 base instruction set과 extension 구조를 가진다. 이는 instruction semantics를 constraints로 구현하고 audit하는 데 유리하다.

Client portability

Ethereum execution client를 전용 ZK language로 전부 재작성하는 대신, 기존 client 또는 STF implementation을 RISC-V guest target으로 compile하는 접근이 가능하다.

Cross-zkVM standardization

Ethereum Foundation의 zkVM Standards v0는 Ethereum execution client가 여러 zkVM을 지원할 수 있도록 다음 세 가지를 표준화하기 시작했다.

RV64IM + Zicclsm target architecture
C interface for optimized precompiles
C interface for private input과 public output I/O

다만 이는 동일한 binary를 모든 zkVM에서 그대로 실행하는 binary compatibility가 아니다. 각 zkVM별 recompilation과 relinking은 여전히 필요하며, memory layout과 backend semantics도 implementation마다 다를 수 있다.

6. 주요 zkVM 설계 방식

범용 zkVM은 동일한 목표를 추구하지만 내부 architecture는 크게 다르다.

Project 또는 방식	핵심 설계
SP1	일반 언어를 RISC-V로 compile하는 developer-oriented zkVM
RISC Zero	RV32IM execution, method image ID와 receipt 기반 verification
OpenVM	중앙 CPU chip이 없는 modular `no-CPU` architecture
Jolt	Lookup argument와 sumcheck 중심의 RISC-V proving
Custom VM	Cairo, Miden과 같은 ZK-oriented ISA
Other ISA	MIPS 및 기타 VM execution proving

SP1

SP1은 RISC-V program execution을 증명하며 Rust, C, C++ 등 RISC-V target을 지원하는 일반-purpose zkVM이다. 최신 Ethereum proving 방향에서는 Ethereum execution client를 guest program으로 실행하는 용도로도 사용된다.

RISC Zero

RISC Zero는 RV32IM을 구현하며 guest ELF의 cryptographic identifier인 image ID와 execution 결과를 포함하는 receipt 개념을 제공한다. 긴 계산을 segment로 분리하는 continuations와 recursive proving을 사용해 unbounded computation, constant-size proof, aggregation과 composition을 지원한다.

OpenVM

OpenVM은 전통적인 중앙 CPU table 대신 instruction executor chip들이 execution trace를 공동으로 관리하는 no-CPU architecture를 사용한다. Custom instruction과 cryptographic operation을 extension으로 추가할 수 있도록 proof system과 ISA를 모듈화한 것이 특징이다.

Jolt

Jolt는 RISC-V instruction을 lookup 중심으로 표현하고 sumcheck protocol을 이용해 많은 연산을 일괄 검증한다. 복잡한 non-linear instruction을 큰 arithmetic circuit으로 직접 표현하는 대신 lookup table로 이동시키는 설계다.

이들 구현의 차이는 단순히 어느 것이 가장 빠른가로 정리할 수 없다. 중요한 비교 축은 다음과 같다.

Supported ISA and extensions
Guest language and dependency compatibility
Proving latency
Prover memory requirement
Proof size
Security level
Recursion design
On-chain verification cost
Precompile coverage
Auditability
Formal verification coverage
Hardware portability
License and governance

7. Precompile은 단순한 편의 기능이 아니다

일반 CPU instruction만 사용해 hash, elliptic curve, big integer와 pairing을 실행하면 native execution에서는 문제가 없더라도 proving cost가 급격히 증가할 수 있다.

예를 들어 다음 계산은 zkVM instruction trace에서 특히 비싸다.

Keccak-256
SHA-256
BLAKE2
Modular exponentiation
secp256k1
BN254 pairing
BLS12-381
Large integer arithmetic

zkVM precompile 또는 coprocessor는 이러한 연산을 전용 circuit이나 chip에서 실행한 뒤 CPU execution과 lookup 또는 bus argument로 연결한다.

즉, precompile은 다음 trade-off를 만든다.

More general VM instructions
        ↓
Simpler architecture, slower proving

More specialized precompiles
        ↓
Faster proving, larger trusted computing base

Ethereum zkVM Standards v0가 precompile C interface를 별도로 표준화한 이유도 Ethereum execution client가 zkVM별 custom syscall에 종속되지 않도록 하기 위해서다.

8. zkEVM이라는 용어는 세 가지로 나눠야 한다

8.1 L2 zkEVM rollup

L2 zkEVM은 Ethereum 외부에서 transaction을 실행하고, 새로운 state root가 올바른 execution 결과라는 validity proof를 Ethereum L1 verifier contract에 제출한다.

L2 rollup architecture에는 proof system 이외에도 다음 요소가 포함된다.

Sequencer
Data availability
State commitment
Bridge
Upgrade authority
Escape hatch
Forced inclusion
Prover network
Settlement contract

Validity proof는 invalid state transition을 막지만 data availability, censorship, centralized sequencing 또는 governance risk를 자동으로 해결하지 않는다.

또한 특정 L2 제품의 성공과 zkEVM 기술의 성공은 동일하지 않다. Polygon zkEVM Mainnet Beta는 기술적으로 EVM-equivalent proving을 구현했지만, 2026년 7월 3일 sequencer가 종료돼 더 이상 새로운 block을 생성하지 않는다. 이는 proof technology의 가능성과 product adoption 및 business strategy가 별개의 문제라는 사례다.

8.2 Ethereum L1 zkEVM

Ethereum L1 zkEVM은 L2 rollup을 의미하지 않는다. Ethereum mainnet block 자체의 execution correctness를 proof로 검증하는 구조다.

현재 Ethereum validation은 대략 다음과 같다.

Block proposer
      │
      ▼
Every validating node
      │
      └── Re-execute all transactions

이를 N-of-N re-execution이라고 표현한다.

L1 zkEVM이 목표로 하는 구조는 다음과 같다.

Block
  │
  ├── Prover A → Proof A
  ├── Prover B → Proof B
  └── Prover C → Proof C
                    │
                    ▼
         Validators verify proofs

Ethereum 공식 roadmap은 이를 1-of-N proving 모델로 설명한다. 하나의 올바른 proof만 있어도 다수 node가 transaction을 모두 재실행하지 않고 execution validity를 확인할 수 있다.

L1에서는 Type 1, 즉 Ethereum의 exact semantics를 증명할 수 있는 fully Ethereum-equivalent zkEVM이 필요하다. Opcode behavior나 edge case가 달라지면 단순 compatibility bug가 아니라 consensus split으로 이어질 수 있기 때문이다.

8.3 Native rollup

Native rollup은 rollup이 자체 zkEVM proof system을 구현하는 대신 Ethereum L1이 제공하는 State Transition Function verification을 재사용하는 개념이다.

EIP-8079는 EXECUTE precompile을 추가해 Ethereum STF를 execution layer에 노출하는 방식을 제안한다. 이를 사용하면 EVM-equivalent rollup이 Ethereum의 execution semantics와 proof infrastructure를 공유할 수 있다.

다만 native rollup에는 제한도 있다.

Custom opcode 사용 제한
Custom precompile 사용 제한
Custom transaction type 사용 제한
Ethereum upgrade에 강하게 결합
L1 proof infrastructure에 의존
Rollup 고유 execution semantics를 유지하기 어려움

2026년 7월 현재 EIP-8079는 Draft이며 precompile address, proof-carrying transaction, re-execution 대 ZK proof 설계, test case, reference implementation과 security consideration에 TBD가 남아 있다. 따라서 구현이 확정된 protocol feature가 아니다.

9. Ethereum L1 zkEVM 로드맵

Ethereum Foundation이 제시하는 진행 순서는 크게 두 단계다.

Optional Execution Proofs
          │
          ▼
Production experimentation
          │
          ▼
Mandatory Execution Proofs
          │
          ▼
Higher gas limit and ZK-based L1 scaling

Phase 1: Optional Execution Proofs

EIP-8025는 validator가 execution client를 사용해 block을 재실행하는 기존 방식 외에 execution proof를 받아 검증할 수 있도록 두 가지 opt-in mode를 제안한다.

Proof-generating node
Stateless validating node 또는 zkAttester

Optional phase에서는 proof가 늦거나 존재하지 않아도 validator가 기존 execution client를 사용해 attestation할 수 있다. 따라서 proof system이 즉시 consensus-critical component가 되지는 않는다.

Ethereum Foundation의 zkEVM workstream은 EIP-8025를 Glamsterdam 다음 fork인 Hegotá 후보로 제안했다. 그러나 2026년 7월 18일 현재 공식 EIP registry에서는 Stagnant로 표시되며 rationale, test cases, reference implementation과 security consideration도 TODO 상태다.

따라서 현재 상태는 다음과 같이 표현해야 한다.

EIP-8025는 Ethereum Foundation zkEVM workstream이 Hegotá 포함을 추진하는 proposal이지만, 채택 또는 fork inclusion이 확정된 상태는 아니다.

Phase 2: Mandatory Execution Proofs

장기적으로는 validator가 execution proof를 block validity의 필수 조건으로 사용하고, full transaction re-execution 의존성을 줄이는 단계다.

이 단계가 실현되면 gas limit을 높여도 모든 validating node의 execution hardware requirement가 비례해 증가하지 않게 된다.

다만 mandatory proof 전환에는 다음이 필요하다.

Proof availability guarantee
Multiple independent zkVMs
Multiple independent STF implementations
Prover incentives
Censorship-resistant proof market
Failure and fallback semantics
Consensus-safe verifier
Stable proof system specification
Formal security arguments

현재 mandatory execution proof를 확정하는 final EIP 또는 fork schedule은 없다. Ethereum Foundation의 공개 roadmap도 optional proof를 현재 단계, mandatory proof를 후속 단계로 표시한다.

10. Real-time proving은 어디까지 왔는가

Ethereum block slot은 약 12초다. Network propagation과 attestation 시간을 고려하면 proof는 그보다 짧은 시간에 생성돼야 한다.

Ethereum Foundation은 2025년 7월 real-time proving target을 다음과 같이 정의했다.

Mainnet block의 최소 99%를 10초 이내에 증명
Initial minimum 100-bit security
Long-term 128-bit security
Proof size 300 KiB 이하
Trusted setup을 사용하는 recursive wrapper에 의존하지 않음
On-prem hardware capital expenditure 목표 약 100,000달러 이하

2025년 12월 Ethereum Foundation은 target hardware에서 zkVM들이 Ethereum block의 99%를 10초 이내에 증명하는 수준에 도달했다고 발표했다. 또한 latency가 16분에서 16초 수준으로 감소했고 cost가 약 45배 줄었다고 보고했다.

그러나 이것을 production readiness와 동일시해서는 안 된다.

현재 핵심 과제는 다음으로 이동했다.

Provable security
Proof size
Worst-case block latency
Formal verification
Multiproof orchestration
Client and network integration
Prover decentralization
Operational reliability

Ethereum Foundation이 제시한 후속 security milestone은 다음과 같다.

Milestone	Target
Glamsterdam 단계	100-bit provable security, proof ≤ 600 KiB
H-star 단계	128-bit provable security, proof ≤ 300 KiB, formal recursion soundness argument

2026년 7월 18일 기준, 이 milestone을 모든 참여 zkVM이 최종 충족했다는 후속 공식 결과는 확인되지 않는다. 따라서 “real-time performance target은 상당 부분 달성됐지만 mainnet-grade security target은 계속 진행 중”이라고 정리하는 것이 적절하다.

11. zkVM benchmark에서 봐야 할 지표

Proving performance를 단일 숫자로 비교하면 거의 항상 잘못된 결론이 나온다.

최소한 다음 지표를 함께 봐야 한다.

Latency

P50 proving time
P95/P99 proving time
Worst-case adversarial block
End-to-end latency
Recursive compression latency

Hardware

GPU model과 수
CPU와 memory
Network topology
On-prem 또는 cloud
Peak memory usage
Power consumption

Proof characteristics

Final proof size
Verification time
Verification gas
Security bits
Trusted setup requirement
Recursion assumptions

Workload

Ethereum block gas
Opcode composition
Precompile usage
State access pattern
Guest client implementation
Compiler options
zkVM version

Ethproofs는 block별 proving time, latency, cost, proof size, cycle과 hardware metadata를 수집해 zkVM을 비교하는 public benchmark infrastructure를 제공한다.

Compiler도 proving cost에 직접 영향을 준다. RISC Zero와 SP1을 대상으로 한 연구에서는 일반 LLVM optimization level이 zkVM performance를 40% 이상 개선할 수 있었지만, 전통 CPU에 비해서는 효과가 제한적이었다. 이는 기존 compiler가 cache, branch prediction과 instruction-level parallelism을 기준으로 최적화되며, constraint count나 lookup cost에는 최적화돼 있지 않기 때문이다.

향후에는 -O3 같은 일반 optimization보다 다음이 중요해질 가능성이 크다.

Constraint-aware compiler passes
Precompile-aware lowering
Memory-access minimization
Branch and control-flow normalization
Proof-cost profiling
zkVM-specific superoptimization

12. 보안에서 가장 중요한 것은 proof system만이 아니다

zkVM security는 다음 전체 stack의 정확성에 의존한다.

Application logic
Compiler
Guest binary
Host / guest interface
Witness generator
ISA implementation
Memory model
Circuit constraints
Lookup and bus arguments
Polynomial commitment
Fiat–Shamir transcript
Recursion
Verifier
Verification key management

이 중 하나라도 underconstrained 상태라면 malicious prover가 잘못된 execution을 valid proof로 만들 가능성이 생긴다.

Soundness와 completeness를 구분해야 한다

Soundness failure: 잘못된 execution이 proof를 통과함
Completeness failure: 올바른 execution인데 proof를 만들거나 검증하지 못함
Liveness failure: proof가 deadline 내 생성되지 않음

Soundness failure는 asset theft나 invalid state transition으로 이어질 수 있다.

Completeness와 liveness failure도 Ethereum L1 환경에서는 adversarial block을 이용한 denial-of-service 또는 missed attestation 문제로 이어질 수 있다.

공개된 실제 사례

RISC Zero는 2025년 RV32IM circuit에 missing constraint가 있어 일부 instruction에서 malicious prover가 register 값을 혼동할 수 있는 critical vulnerability를 공개하고 영향을 받은 verifier를 중지한 바 있다.

Ethereum Foundation의 SP1 formal verification 검토에서는 JALR specification handling 문제가 발견됐다. 해당 문제는 invalid proof를 허용하는 soundness bug라기보다는 valid RISC-V execution에서 prover가 실패할 수 있는 completeness 및 potential DoS 문제였으며, SP1 v6.1.0에서 수정됐다고 보고됐다.

이 사례들은 formal verification이나 audit이 불필요하다는 뜻이 아니다. 반대로 다음 교훈을 준다.

무엇을 formal verification으로 증명했는지와 무엇을 증명하지 않았는지를 정확히 구분해야 한다.

Formal verification에서 여전히 신뢰하거나 별도로 검증해야 하는 요소에는 다음이 포함될 수 있다.

Formal specification 자체의 정확성
Rust 또는 circuit code의 Lean extraction
Witness generator
Memory consistency
Chip 간 bus argument
Lookup table correctness
Recursion glue
Compiler
Verifier implementation
Build reproducibility

따라서 formal verification은 audit, differential testing, fuzzing, ISA compliance testing과 implementation diversity를 대체하지 않는다.

13. Multiproof strategy가 필요한 이유

Ethereum이 하나의 zkVM과 하나의 Ethereum client implementation만 사용하면 해당 implementation의 bug가 Ethereum consensus bug가 된다.

Ethereum Foundation은 이를 완화하기 위해 여러 zkVM과 여러 Ethereum STF implementation의 proof를 함께 확인하는 multiproof strategy를 제안한다.

진정한 diversity는 단순히 prover server를 여러 개 운영하는 것이 아니다.

Different prover operators
            ≠
Independent proof diversity

보다 강한 구조는 다음과 같다.

zkVM A + Client implementation X
zkVM B + Client implementation Y
zkVM C + Client implementation Z

여기서 독립성이 필요한 계층은 다음과 같다.

Proof protocol
PCS and hash function
zkVM circuit implementation
Compiler and guest toolchain
Ethereum client implementation
Hardware and prover software
Verification implementation

다만 proof를 여러 개 요구할수록 다음 비용이 증가한다.

Proof bandwidth
Verification cost
Operational complexity
Liveness dependency
Coordination overhead

따라서 실제 consensus rule은 N-of-N, M-of-N, fallback execution 또는 다른 threshold model 중 하나를 선택해야 한다. 이 부분은 아직 최종 specification이 아니다.

14. zkVM은 Ethereum만을 위한 기술이 아니다

zkVM이 주목받는 이유는 blockchain scaling에만 있지 않다.

일반-purpose zkVM은 다음과 같은 verifiable computation을 구현할 수 있다.

Verifiable database query
Cross-chain state verification
Light client
Verifiable build and software supply chain
Proof of correct ML inference
Identity and credential verification
Compliance computation
Off-chain game simulation
Optimistic system의 fault proof 대체
Coprocessor for smart contracts

다만 general-purpose zkVM이 모든 workload에 최적인 것은 아니다.

CPU instruction을 하나씩 증명하는 방식보다 domain-specific circuit이 훨씬 효율적인 영역도 있다.

예를 들어 ML inference에서는 RISC-V CPU instruction을 전부 거치는 것보다 tensor operation이나 ONNX graph를 직접 arithmetization하는 zkML system이 더 효율적일 수 있다. Jolt Atlas 역시 일반 CPU emulation 대신 ONNX tensor operation에 lookup-centric proving을 직접 적용한다.

따라서 미래는 하나의 universal zkVM이 모든 circuit을 대체하는 구조보다는 다음에 가깝다.

General zkVM
      +
Domain-specific coprocessors
      +
Specialized circuits
      +
Recursive proof composition

15. 기존 전망의 업데이트

2022년 주장	2026년 평가
ZK는 scaling과 privacy를 함께 제공한다	Scaling proof와 privacy property를 분리해야 한다
SNARK와 STARK가 양대 분류다	실제 구현은 modular proof stack이다
STARK는 더 빠르고 gas가 낮다	Workload, PCS, recursion, verifier에 따라 달라진다
Contract마다 다른 circuit이 필요하다	zkVM은 VM/ISA circuit으로 여러 program을 증명한다
RISC-V 또는 WASM zkVM이 zkEVM을 대체한다	RISC-V zkVM이 zkEVM의 기반이 되고 있다
Native zkEVM이 Ethereum의 미래다	공식 roadmap이 됐지만 아직 production consensus 기능은 아니다
General zkVM은 모든 개발자를 Web3로 유입시킨다	Toolchain barrier는 낮췄지만 proving cost와 guest compatibility는 여전히 제약이다
EVM compatibility가 핵심 경쟁력이다	Security, real-time proving, standardization과 diversity가 더 중요한 경쟁 축으로 이동했다
Polygon zkEVM이 대표적 미래 사례다	Polygon zkEVM product는 2026년 종료됐지만 proving 기술과 연구는 계속 발전 중이다
Formal verification이 보안을 해결한다	Scope, assumptions와 trusted computing base를 명확히 해야 한다

16. 최종 결론

2022년에는 zkEVM과 general zkVM이 서로 다른 미래를 향해 경쟁하는 것처럼 보였다.

2026년 현재 두 기술은 다음 구조로 수렴하고 있다.

General-purpose zkVM
          │
          ▼
Ethereum STF guest program
          │
          ▼
L1 zkEVM execution proof
          │
          ▼
Optional proof verification
          │
          ▼
Mandatory proof verification
          │
          ▼
Potential native rollups

핵심 변화는 세 가지다.

첫째, zkVM과 zkEVM의 관계가 바뀌었다

General zkVM은 zkEVM의 대체재가 아니라 zkEVM을 구현하는 공통 infrastructure가 됐다.

둘째, proving speed만으로는 충분하지 않다

Real-time proving은 target hardware 기준으로 빠르게 발전했지만 Ethereum L1에 필요한 것은 빠른 demo가 아니라 mainnet-grade soundness, worst-case liveness, formal specification, reproducibility와 independent implementation diversity다.

셋째, Ethereum의 validation architecture 자체가 바뀔 수 있다

현재 Ethereum은 모든 validating node가 모든 transaction을 재실행한다. L1 zkEVM은 이를 specialized prover가 실행하고 validator가 succinct proof를 확인하는 구조로 바꾸려 한다.

이 변화가 실제로 완료된다면 Ethereum scaling의 bottleneck은 validator execution hardware에서 다음 영역으로 이동한다.

Prover market
Proof availability
Cryptographic security
Networking
Governance
Client diversity

따라서 2026년 시점의 결론은 다음과 같다.

General zkVM is becoming the common proving substrate for verifiable computation.

zkEVM is evolving from an L2 compatibility technology into Ethereum’s execution-verification infrastructure.

The decisive competition is no longer SNARK versus STARK or zkVM versus zkEVM. It is a competition in security, proving latency, interoperability, decentralization and implementation diversity.