ZKVM 생존 전략: 파벌 갈등을 자세히 알아보기

2023.01.31

ZKVM 생존 전략: 파벌 갈등을 자세히 알아보기

지난 2022년에는 롤업(Rollup)에 관한 주요 논의가 대부분 ZkEVM에 집중된 것처럼 보였지만, ZkVM 역시 또 다른 확장 수단이라는 점을 잊어서는 안 된다.

2023.01.31 - 04:27:24

ZKVMZKEVM

Web3 심층 보도에 집중하고 흐름을 통찰

지난 2022년에는 롤업(Rollup)에 관한 주요 논의가 대부분 ZkEVM에 집중된 것처럼 보였지만, ZkVM 역시 또 다른 확장 수단이라는 점을 잊어서는 안 된다.

저자: Bryan, IOSG Ventures

Xin Gao, p0xeidon의 Boyuan, Taiko의 Daniel 및 Sin7Y가 본문에 대한 지원과 수정 제안을 해주신 데 감사드립니다!

서론:

지난 2022년 동안 롤업(rollup)에 관한 주요 논의는 주로 ZkEVM에 집중되었지만, ZkVM 역시 또 다른 확장 수단이라는 점을 잊어서는 안 된다. ZkEVM이 본고의 주제는 아니지만, ZkVM과 ZkEVM 사이의 몇 가지 차원에서의 상이점을 되새겨볼 필요가 있다.

1. 호환성: 둘 다 확장을 목표로 하지만 초점은 다르다. ZkEVM은 기존 EVM과의 직접적인 호환성을 우선시하는 반면, ZkVM은 완전한 확장을 목표로 하며, 즉 dapp의 로직과 성능을 최적화하는 것을 목표로 한다. 호환성은 가장 중요한 요소가 아니다. 기반 인프라가 마련되면 EVM 호환성도 구현할 수 있다.

2. 성능: 두 시스템 모두 예측 가능한 성능 병목 현상을 가지고 있다. ZkEVM의 주요 병목은 EVM과의 호환성 유지라는 부담에서 비롯되며, 이는 ZK 증명 시스템 내에서 불필요한 오버헤드를 초래한다. ZkVM의 병목은 명령어 세트(ISA) 도입으로 인해 최종적으로 생성되는 제약 조건이 더욱 복잡해지는 데서 발생한다.

3. 개발자 경험: Type II ZkEVM (예: Scroll, Taiko)은 EVM 바이트코드 수준 이상의 코드가 ZkEVM을 통해 제로지식 증명을 생성할 수 있도록 하는 것이 핵심이다. ZkVM의 경우 두 가지 방향이 있다. 하나는 자체 DSL(예: Cairo)을 만드는 것이고, 다른 하나는 기존에 잘 정립된 언어인 C++/Rust와의 호환을 목표로 하는 것이다(예: Risc0). 앞으로 우리는 기존의 Solidity 이더리움 개발자들이 ZkEVM으로 비용 없이 전환할 수 있게 될 것이며, 보다 강력하고 새로운 애플리케이션들은 ZkVM 위에서 실행될 것으로 예상한다.

ZKVM 생존 전략: 파벌 간 경쟁 심층 분석

많은 사람들이 이 그림을 기억할 것이다. CairoVM이 ZkEVM 파벌 갈등에서 벗어나 있는 근본적인 이유는 설계 철학의 차이 때문이다.

ZkVM을 논하기 전에 먼저 고민해야 할 것은 블록체인에서 ZK 증명 시스템을 어떻게 구현할 것인가 하는 점이다. 대략적으로 두 가지 방법이 있다: 회로 기반 시스템(circuit based)과 가상머신 기반 시스템(vm-based).

우선, 회로 기반 시스템은 프로그램(program)을 직접 제약 조건(constraints)으로 변환하여 증명 시스템(proving system)에 입력한다. 가상머신 기반 시스템은 명령어 세트(ISA)를 통해 프로그램을 실행하면서 실행 궤적(execution trace)을 생성한다. 이 실행 궤적은 이후 제약 조건으로 매핑되어 증명 시스템에 전달된다.

회로 기반 시스템에서는 각각의 머신(machine)이 프로그램 계산 과정 전체에 걸쳐 제약을 수행한다. 반면, 가상머신 기반 시스템에서는 ISA가 회로 생성기(circuit generator)에 내장되어 프로그램의 제약 조건을 생성하며, 회로 생성기는 명령어 세트, 실행 주기, 메모리 등을 제한한다. 가상머신은 일반성을 제공하는데, 어떤 머신이라도 해당 프로그램의 실행 조건이 위 제한 내에 있으면 실행 가능하다는 의미이다.

가상머신 내에서 ZKP 프로그램은 다음과 같은 흐름을 거친다.

ZKVM 생존 전략: 파벌 간 경쟁 심층 분석

출처: Bryan, IOSG Ventures

장단점:

- 개발자(developer) 관점에서, 회로 기반 시스템에서는 개발자가 각 제약 조건의 비용에 대해 깊이 이해해야 한다. 반면, 가상머신 프로그램 작성에서는 회로가 정적(static)이므로 개발자는 명령어(instructions)에 더 집중하면 된다.

- 검증자(verifier) 관점에서, 동일한 순수 SNARK 백엔드를 사용한다고 가정할 때, 회로 기반 시스템과 가상머신은 회로의 일반성(generality) 측면에서 큰 차이가 있다. 회로 시스템은 각 프로그램마다 다른 회로를 생성하지만, 가상머신은 다양한 프로그램에 대해 동일한 회로를 생성한다. 이는 롤업 환경에서 회로 시스템이 L1에 여러 검증 계약(verifier contract)을 배포해야 함을 의미한다.

- 애플리케이션(application) 관점에서, 가상머신은 메모리 모델(memory)을 설계에 내장함으로써 애플리케이션의 로직을 더욱 복잡하게 만들지만, 회로 시스템은 프로그램의 성능 향상을 목적으로 한다.

- 시스템 복잡성(complexity) 관점에서, 가상머신은 메모리 모델, 호스트(host)와 게스트(guest) 간 통신 등 더 많은 복잡성을 시스템에 포함시키며, 회로 시스템은 상대적으로 더 단순하다.

다음은 현재 L1/L2에서 회로 기반 및 가상머신 기반 프로젝트들의 개요이다.

ZKVM 생존 전략: 파벌 간 경쟁 심층 분석

출처: Bryan, IOSG Ventures

가상머신 설계 원칙

가상머신에는 두 가지 핵심 설계 원칙이 있다.

첫째, 프로그램이 올바르게 실행되었음을 보장해야 한다. 즉 출력(output)(= 제약 조건 constraint)이 입력(input)(= 프로그램 program)과 정확히 일치해야 한다. 일반적으로 이는 ISA 명령어 세트를 통해 달성된다.
둘째, 컴파일러(compiler)가 고급 언어를 적절한 제약 형식으로 변환할 때 올바르게 작동해야 한다.

1. ISA 명령어 세트

회로 생성기의 작동 방식을 규정한다. 주요 책임은 명령어(instructions)를 제약 조건(constraint)에 올바르게 매핑하는 것이며, 이후 이러한 제약 조건은 증명 시스템(proving system)에 전달된다. ZK 시스템에서는 모두 RISC(축소 명령어 세트)를 사용한다. ISA 선택에는 두 가지 방향이 있다.

첫 번째는 자체적으로 맞춤형 ISA(custom ISA)를 설계하는 것으로, Cairo의 설계에서 볼 수 있다. 일반적으로 다음과 같은 네 가지 유형의 제약 로직이 존재한다.
맞춤형 ISA의 기본 설계 목표는 제약 조건을 최소화하여 프로그램 실행과 검증 속도를 모두 빠르게 만드는 것이다.
두 번째는 기존 ISA(existing ISA)를 활용하는 것으로, Risc0의 설계에서 채택되었다. 단순히 간결한 실행 시간을 목표로 하는 것을 넘어서, 기존 ISA(예: Risc-V)는 프론트엔드 언어(front-end language) 및 백엔드 하드웨어(backend hardware) 친화성이라는 추가적인 장점을 제공한다. 그러나 해결되지 않은 문제는, 검증 시간 측면에서 다소 열세일 가능성인데, 이는 Risc-V의 주요 설계 목표가 검증 시간이 아니기 때문이다.

2. 컴파일러(Compiler)

간단히 말해, 컴파일러는 프로그래밍 언어를 점진적으로 기계어로 번역한다. ZK 환경에서는 C, C++, Rust 등의 고급 언어를 제약 시스템(R1CS, QAP, AIR 등)의 저수준 코드 표현으로 변환한다는 의미이다. 두 가지 접근 방법이 있다.

기존 ZK 회로 표현(existing circuit representations)을 기반으로 컴파일러를 설계하는 것. 예를 들어, ZK에서는 Bellman처럼 직접 호출 가능한 라이브러리(library)나 Circom 같은 저수준 언어로 회로 표현이 시작된다. 다양한 표현 형식을 통합하기 위해 Zokrates 같은 컴파일러(DSL이기도 함)는 임의의 낮은 수준 표현 형식으로 컴파일할 수 있는 추상화 계층을 제공하려 한다.
기존 컴파일러 인프라(compiler infrastructure)를 기반으로 구축하는 것. 기본 아이디어는 다수의 프론트엔드와 백엔드를 지원하는 중간 표현(intermediate representation)을 활용하는 것이다.

Risc0의 컴파일러는 multi-level intermediate representation(MLIR) 기반으로, 여러 IR을 생성할 수 있다(LLVM과 유사). 다양한 IR은 개발자에게 유연성을 제공하는데, 각 IR이 서로 다른 설계 목적을 갖고 있기 때문이다. 예를 들어 일부 IR은 하드웨어 최적화에 특화되어 있으므로 개발자의 필요에 따라 선택할 수 있다. GCC를 사용하는 vnTinyRAM과 TinyRAM에서도 유사한 사고방식을 확인할 수 있다. zkSync 또한 컴파일러 인프라를 활용하는 또 다른 사례이다.

또한 CirC와 같이 ZK 전용 컴파일러 인프라도 있으며, LLVM의 일부 설계 개념을 차용하고 있다.

위 두 가지 핵심 설계 외에도 고려해야 할 다른 요소들이 있다.

1. 시스템 보안(security)과 검증 비용(verifier cost) 간의 균형

시스템이 사용하는 비트 수가 많을수록(즉, 보안성이 높을수록) 검증 비용도 증가한다. 보안성은 키 생성기(예: SNARK에서 타원 곡선)에 반영된다.

2. 프론트엔드 및 백엔드와의 호환성(compatibility)

호환성은 회로의 중간 표현(intermediate representation)의 효율성에 달려 있다. IR은 정확성(프로그램 출력이 입력과 일치하는지 + 출력이 증명 시스템 요구사항을 충족하는지)과 유연성(여러 프론트엔드 및 백엔드 지원) 사이의 균형을 유지해야 한다. 만약 IR이 처음부터 R1CS 같은 저차 제약 시스템을 위한 것으로 설계되었다면, AIR과 같은 고차 제약 시스템과의 호환은 어렵다.

3. 효율성 향상을 위한 수작업(hand-crafted) 회로 설계

범용 모델(general purpose)의 단점은 복잡한 명령이 필요 없는 간단한 연산에 대해서도 효율이 낮다는 점이다.

이전의 몇 가지 이론들을 간략히 설명하자면:

Pinocchio 프로토콜 이전: 검증 가능한 컴퓨팅을 구현했으나, 검증 시간이 매우 느렸다.
Pinocchio 프로토콜: 검증 가능성과 검증 성공률 측면에서 이론적 실현 가능성을 제공했다(즉, 프로그램 실행 시간보다 짧은 검증 시간). 회로 기반 시스템이다.
TinyRAM 프로토콜: Pinocchio에 비해 TinyRAM은 마치 가상머신처럼 동작하며 ISA를 도입하여 RAM 접근, 제어 흐름(conttrol flow) 등의 제약에서 벗어났다.
vnTinyRAM 프로토콜: 키 생성(key generation)이 각 프로그램에 의존하지 않도록 하여 추가적인 일반성을 제공한다. 회로 생성기를 확장하여 더 큰 프로그램을 처리할 수 있다.

위 모델들은 모두 SNARK를 백엔드 증명 시스템으로 사용하지만, 특히 가상머신을 다룰 때는 STARK와 Plonk가 더 적합한 백엔드로 여겨진다. 근본적으로 그들의 제약 시스템이 CPU와 같은 로직 구현에 더 적합하기 때문이다.

다음으로, 본고에서는 STARK 기반 가상머신 Risc0, MidenVM, CairoVM에 대해 소개하겠다. 간단히 말해, 모두 STARK를 증명 시스템으로 사용하지만 각각 차이점이 있다.

Risc0는 Risc-V를 활용하여 명령어 세트의 간결성을 실현한다. R0는 MLIR을 통해 컴파일되며, 이는 LLVM-IR의 변형으로 Rust, C++ 등 기존의 다양한 범용 프로그래밍 언어를 지원한다. Risc-V는 하드웨어 친화성이라는 추가적인 장점도 지닌다.
Miden은 이더리움 가상머신(EVM)과의 호환을 목표로 한다. 본질적으로 EVM 롤업이다. Miden은 현재 자체 프로그래밍 언어를 보유하고 있지만, 향후 Move 언어 지원도 추진 중이다.
Cairo VM은 Starkware가 개발했다. 이 세 시스템이 사용하는 STARK 증명 시스템은 Eli Ben-Sasson이 발명하였으며, 현재 Starkware의 회장이다.

이제 그들의 차이점을 좀 더 깊이 살펴보자.

ZKVM 생존 전략: 파벌 간 경쟁 심층 분석

*위 표를 어떻게 읽어야 할까? 몇 가지 주석...

●Word size(워드 크기): 이러한 가상머신이 기반하는 제약 시스템은 AIR이며, CPU 아키텍처와 유사한 기능을 한다. 따라서 CPU 워드 크기(32/64비트)를 선택하는 것이 적절하다.

●Memory access(메모리 접근): Risc0가 레지스터(register)를 사용하는 이유는 Risc-V 명령어 세트가 레지스터 기반으로 설계되었기 때문이다. Miden은 데이터 저장을 위해 주로 스택(stack)을 사용하는데, 이는 AIR의 기능이 스택과 유사하기 때문이다. CairoVM은 일반 목적 레지스터(general-purpose register)를 사용하지 않는다. 이는 Cairo 모델에서 메인 메모리 접근 비용이 낮기 때문이다.

●Program feed(프로그램 실행): 서로 다른 방법은 트레이드오프를 수반한다. 예를 들어, mast root 방식은 명령어 처리 시 디코딩을 필요로 하므로, 실행 단계가 많은 프로그램에서 증명자의 비용이 높아진다. Bootloading 방식은 증명자 비용과 검증자 비용 사이의 균형을 유지하면서 동시에 프라이버시를 보존하려 시도한다.

●Non-determinism(비결정성): 비결정성은 NP-complete 문제의 중요한 속성이다. 이를 활용하면 과거 실행을 빠르게 검증할 수 있다. 반대로, 이는 더 많은 제약 조건을 추가하므로 검증 측면에서 타협이 필요하다.

●Acceleration on complex operations(복잡 연산 가속화): 일부 계산은 CPU에서 느리게 동작한다. 예를 들어 XOR, AND 같은 비트 연산, ECDSA 같은 해시 프로그램(hash program), 범위 검사(range-check) 등이 있다. 대부분 블록체인/암호화 기술에서는 기본적이지만 CPU에서는 기본이 아닌 연산들이다(비트 연산 제외). 이러한 연산을 DSL로 직접 구현하면 증명 사이클(cycle) 소모가 급격히 증가할 수 있다.

●Permutation/multiset(순열/다중집합): 대부분의 zkVM에서 널리 사용되며, 두 가지 목적을 갖는다. 1) 완전한 실행 궤적(execution trace) 저장을 줄여 검증자 비용을 낮추는 것 2) 검증자가 완전한 실행 궤적을 알고 있음을 증명하는 것.

마지막으로笔者는 Risc0의 현재 발전 상황과 필자를 기대하게 하는 점에 대해 이야기하고자 한다.

R0의 현재 발전 상황:

a. 자체 개발 중인 "Zirgen" 컴파일러 인프라. 기존 ZK 전용 컴파일러들과의 성능 비교가 흥미롭다.

b. 필드 확장(field extension)과 같은 흥미로운 혁신으로 더 견고한 보안 파라미터와 더 큰 정수 연산이 가능해졌다.

c. ZK 하드웨어 및 ZK 소프트웨어 기업 간 통합에서 발생하는 도전 과제를 경험하면서, Risc0는 하드웨어 추상화 계층을 도입하여 하드웨어 측면의 개발을 용이하게 하고 있다.

d. 아직 진행 중인 프로젝트!(Work-in-progress)

- 수작업 회로(hand-crafted circuits) 지원, 다양한 해시 알고리즘 지원. 현재 전용 SHA256 회로는 구현되었으나 모든 요구를 충족하지는 못한다.笔者는 어떤 회로를 최적화할지 선택하는 것은 Risc0가 제공하는 사용 사례(use case)에 달려 있다고 믿는다. SHA256은 훌륭한 출발점이다. 다른 한편으로, ZKVM의 위치 설정은 유연성을 제공한다. 예를 들어, Keccak을 굳이 다룰 필요가 없다면 하지 않아도 된다 :)

- 재귀(recursion): 매우 큰 주제로, 본 보고서에서 깊이 다루지는 않겠다. 다만 Risc0가 더 복잡한 사용 사례/프로그램을 지원하려 할수록 재귀가 점점 더 절실해진다는 점을 알아두자. 재귀를 추가로 지원하기 위해 현재 GPU 가속 방안을 하드웨어 측면에서 연구 중이다.

- 비결정성(non-determinism) 처리: 이는 ZKVM이 반드시 다뤄야 하는 속성이지만, 전통적인 가상머신에는 없는 문제이다. 비결정성은 가상머신의 실행 속도를 높이는 데 도움이 될 수 있다. MLIR은 전통적인 가상머신 문제 해결에 상대적으로 능숙하지만, Risc0가 비결정성을 ZKVM 시스템 설계에 어떻게 통합할지 주목된다.