ZKVM 생존의 길, 파벌 간의 싸움을 자세히 설명한 글

저자: Bryan, IOSG Ventures

목차

• ZKP 증명 시스템의 회로 구현 - 회로 기반(circuit-based) VS 가상 머신(vm-based)

• ZKVM의 설계 원칙

• STARK 기반 VM 간의 비교

• 왜 Risc0이 흥미로운가

서론:

지난 2022년 롤업에 대한 주요 논의는 ZkEVM에 집중된 것 같지만, ZkVM도 또 다른 확장 수단이라는 점을 잊지 말아야 합니다. ZkEVM이 본문의 초점은 아니지만, ZkVM과 ZkEVM 간의 몇 가지 차이점을 되새겨볼 가치가 있습니다:

1. 호환성: 두 시스템 모두 확장성을 목표로 하지만, 초점이 다릅니다. ZkEVM은 기존 EVM과의 호환성을 직접 구현하는 데 중점을 두고 있으며, ZkVM은 완전한 확장을 목표로 하여 dapp의 논리와 성능을 최적화하는 데 중점을 둡니다. 호환성은 최우선 사항이 아닙니다. 기본이 잘 구축되면 EVM 호환성도 구현할 수 있습니다.

2. 성능: 두 시스템 모두 예측 가능한 성능 측면의 병목 현상이 있습니다. ZkEVM의 주요 병목은 EVM과의 호환성에서 발생하는 불필요한 비용입니다. ZkVM의 병목은 ISA(명령어 집합)를 도입함으로써 최종 출력의 제약이 더 복잡해지는 데 있습니다.

3. 개발자 경험: Type II ZkEVM(예: Scroll, Taiko)은 EVM 바이트코드와의 호환성을 주로 강조합니다. 즉, 바이트코드 수준 및 그 이상의 EVM 코드는 ZkEVM을 통해 해당하는 제로 지식 증명을 생성할 수 있습니다. ZkVM의 경우, 두 가지 방향이 있습니다. 하나는 자체 DSL(예: Cairo)을 만드는 것이고, 다른 하나는 C++/Rust와 같은 기존의 비교적 성숙한 언어와의 호환성을 목표로 하는 것입니다(예: Risc0). 앞으로 우리는 원주율의 Solidity 이더리움 개발자가 비용 없이 ZkEVM으로 이전할 수 있을 것이며, 더 강력한 애플리케이션은 ZkVM에서 실행될 것입니다.

많은 사람들이 이 이미지를 기억할 것입니다. CairoVM은 ZkEVM 파벌의 본질적인 투쟁에서 벗어난 이유는 설계 사상의 차이 때문입니다.

ZkVM에 대해 논의하기 전에, 우리는 블록체인에서 ZK 증명 시스템을 구현하는 방법에 대해 먼저 생각해야 합니다. 대체로 회로를 구현하는 두 가지 방법이 있습니다 - 회로 기반 시스템(circuit based)과 가상 머신 기반 시스템(vm-based).

우선, 회로 기반 시스템의 기능은 프로그램(program)을 직접 제약 조건(constraints)으로 변환하여 증명 시스템(proving system)으로 전달하는 것입니다. 가상 머신 기반 시스템은 ISA(명령어 집합)를 통해 프로그램을 실행하며, 이 과정에서 실행 추적(execution trace)을 생성합니다. 이 실행 추적은 이후 제약 조건으로 매핑되어 증명 시스템으로 전달됩니다.

회로 기반 시스템에서는 프로그램의 계산이 실행 프로그램을 수행하는 각 머신(machine)에 의해 제약됩니다. 반면, 가상 머신 기반 시스템에서는 ISA가 회로 생성기(circuit generator)에 내장되어 프로그램의 제약(constraints)을 생성하며, 회로 생성기는 명령어 집합, 실행 주기, 메모리 등 여러 제한을 가집니다. 가상 머신은 범용성을 제공하여, 어떤 머신에서도 프로그램을 실행할 수 있도록 합니다. 단, 해당 프로그램의 실행 조건이 위의 제한 범위 내에 있어야 합니다.

가상 머신에서 ZKP 프로그램은 대략 다음과 같은 과정을 거칩니다:

장단점:

• 개발자(developer) 관점에서 보면, 회로 기반 시스템에서 개발하려면 각 제약 조건의 비용에 대해 깊이 이해해야 합니다. 그러나 가상 머신 프로그램을 작성할 때는 회로가 정적이므로 개발자는 명령어(instructions)에 더 신경 써야 합니다.

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

• 애플리케이션(application) 관점에서 보면, 가상 머신은 메모리 모델(memory)을 설계에 내장하여 애플리케이션의 논리를 더욱 복잡하게 만들고, 회로 시스템을 사용하는 목적은 프로그램의 성능을 향상시키는 것입니다.

• 시스템 복잡성(complexity) 관점에서 보면, 가상 머신은 메모리 모델, 호스트(host)와 게스트(guest) 간의 통신 등 더 많은 복잡성을 시스템에 포함시키며, 이에 비해 회로 시스템은 더 간결합니다. 현재 L1/L2에서 회로 기반과 가상 머신 기반의 다양한 프로젝트 미리보기를 아래에서 확인할 수 있습니다:

가상 머신의 설계 원칙

가상 머신에서 두 가지 주요 설계 원칙이 있습니다. 첫째, 프로그램이 올바르게 실행되도록 보장하는 것입니다. 즉, 출력(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)에 친화적인 추가 이점을 제공합니다. 하나의(해결해야 할 가능성이 있는) 문제는 기존 ISA가 검증 시간에서 뒤처질 수 있는지 여부입니다(검증 시간이 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은 고유한 설계 초점이 있으며, 그 중 일부 최적화는 하드웨어에 특별히 초점을 맞추고 있어 개발자가 원하는 대로 선택할 수 있습니다. 유사한 아이디어는 GCC를 사용하는 vnTinyRAM과 TinyRAM에서도 볼 수 있습니다. ZkSync 또한 컴파일러 인프라를 활용하는 또 다른 예입니다.

또한, CirC와 같은 zk를 위한 컴파일러 인프라를 볼 수 있으며, 이는 LLVM의 일부 설계 개념을 차용했습니다. 위의 두 가지 가장 중요한 설계 단계 외에도 몇 가지 다른 고려 사항이 있습니다:

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

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

2. 전면 및 후면과의 호환성(compatibility)

호환성은 회로의 중간 표현(intermediate representation)의 유효성에 따라 달라집니다. IR은 올바름(프로그램의 출력이 입력과 일치하는지 + 출력이 증명 시스템에 부합하는지)과 유연성(다양한 전면 및 후면을 지원하는지) 간의 균형을 이루어야 합니다. IR이 처음에 R1CS와 같은 저차(low-degree) 제약 시스템을 해결하기 위해 설계되었다면, AIR와 같은 더 고차(high-degree) 제약 시스템과의 호환성은 매우 어려워집니다.

3. 효율성을 높이기 위해 수작업으로 제작된(hand-crafted) 회로

범용 모델(general purpose)의 단점은 복잡한 명령어가 필요하지 않은 간단한 작업의 경우 효율성이 낮다는 것입니다. 이전의 몇 가지 이론을 간단히 정리하면,

• Pinocchio 프로토콜 이전: 검증 가능한 계산을 구현했지만 검증 시간이 매우 느림

• Pinocchio 프로토콜: 검증 가능성과 검증 성공률 측면에서 이론적으로 실행 가능성을 제공(즉, 검증 시간이 프로그램 실행 시간보다 짧음), 회로 기반 시스템임

• TinyRAM 프로토콜: Pinocchio 프로토콜에 비해 TinyRAM은 가상 머신과 더 유사하며, ISA를 도입하여 메모리 접근(RAM), 제어 흐름(control 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의 사장입니다.

그들의 차이를 더 깊이 이해해 봅시다:

* 위 표를 읽는 방법에 대한 몇 가지 주석…

●Word size(단어 크기) - 이 가상 머신들이 기반으로 하는 제약 시스템이 AIR이므로, CPU 아키텍처와 유사한 기능을 가지고 있습니다. 따라서 CPU 단어 크기(32/64비트)를 선택하는 것이 적합합니다.

●Memory access(메모리 접근) - Risc0가 레지스터(register)를 사용하는 주된 이유는 Risc-V 명령어 집합이 레지스터 기반이기 때문입니다. Miden은 AIR의 기능이 스택(stack)과 유사하므로 주로 스택을 사용하여 데이터를 저장합니다. CairoVM은 Cairo 모델에서 메모리 접근(main memory) 비용이 낮기 때문에 범용 레지스터(general-purpose register)를 사용하지 않습니다.

●Program feed(프로그램 실행) - 서로 다른 방법은 선택의 여지가 있습니다. 예를 들어, mast root 방법은 명령어를 처리할 때 디코딩이 필요하므로 실행 단계가 많은 프로그램에서 증명자의 비용이 높아집니다. Bootloading 방법은 개인 정보를 유지하면서 증명자 비용과 검증자 비용 간의 균형을 맞추려고 합니다.

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

●Acceleration on complex operations(복잡한 연산의 가속) - 일부 계산은 CPU에서 실행하기 매우 느립니다. 예를 들어, 비트 연산, XOR 및 AND, ECDSA와 같은 해시 프로그램, 범위 검사(range-check) 등은 대부분 블록체인/암호 기술의 원시 연산이지만 CPU의 원시 연산은 아닙니다(비트 연산 제외). 이러한 연산을 DSL을 통해 직접 구현하면 증명의 주기(cycle)가 소모될 수 있습니다.

●Permutation/multiset(순열/다중 집합) - 대부분의 zkVM에서 많이 사용되며, 두 가지 목적이 있습니다 - 1. 전체 실행 추적(execution trace)을 저장하는 것을 줄여 검증자의 비용을 낮추고 2. 검증자가 전체 실행 추적을 알고 있음을 증명합니다. 마지막으로 필자는 Risc0의 현재 발전과 그것이 나를 흥미롭게 만드는 이유에 대해 이야기하고 싶습니다.

R0의 현재 발전:

a. 자체 개발한 "Zirgen"의 컴파일러 인프라가 개발 중입니다. Zirgen과 몇 가지 기존 zk 전용 컴파일러의 성능을 비교하는 것은 흥미로울 것입니다.

b. 필드 확장(field extension)과 같은 몇 가지 흥미로운 혁신이 있어 더 강력한 보안 매개변수를 구현하고 더 큰 정수에서 작업할 수 있습니다.

c. ZK 하드웨어와 ZK 소프트웨어 회사 간의 통합에서 나타나는 도전 과제를 목격하였으며, Risc0는 하드웨어 측면에서 더 나은 개발을 위해 하드웨어 추상화 계층을 사용하고 있습니다.

d. 여전히 진행 중입니다! 개발 중입니다!

• 수작업으로 제작된 회로(hand-crafted circuits)를 지원하며, 여러 해시 알고리즘을 지원합니다. 현재 전용 SHA256 회로가 구현되었지만, 모든 요구를 충족하지는 못합니다. 필자는 어떤 종류의 회로를 최적화할지는 Risc0가 제공하는 사용 사례(use case)에 따라 달라질 것이라고 믿습니다. SHA256은 매우 좋은 출발점입니다. 반면, ZKVM의 위치는 유연성을 제공합니다. 예를 들어, 그들이 원하지 않는 한 Keccak에 대해 신경 쓸 필요가 없습니다 :)
• 재귀(recursion): 이는 큰 주제이며, 필자는 이 보고서에서 깊이 연구하지 않으려 합니다. 알아야 할 것은 Risc0가 더 복잡한 사용 사례/프로그램을 지원하려고 하면서 재귀에 대한 필요성이 더욱 커지고 있다는 것입니다. 재귀를 더욱 지원하기 위해 현재 하드웨어 측면에서 GPU 가속 솔루션을 연구하고 있습니다.
• 비결정성(non-determinism) 처리: 이는 ZKVM이 처리해야 하는 속성이며, 전통적인 가상 머신은 이 문제를 가지고 있지 않습니다. 비결정성은 가상 머신의 실행 속도를 높이는 데 도움이 됩니다. MLIR은 전통적인 가상 머신 문제를 처리하는 데 상대적으로 더 능숙하며, Risc0가 비결정성을 ZKVM 시스템 설계에 어떻게 통합할지는 기대됩니다.

WHAT EXCITES ME:

a. 간단하고 검증 가능하다!

분산 시스템에서 PoW는 높은 수준의 중복성을 요구합니다. 사람들은 서로를 신뢰하지 않기 때문에 동일한 계산을 반복하여 합의에 도달해야 합니다. 그러나 제로 지식 증명을 활용하면 상태의 구현은 1+1=2에 동의하는 것만큼 쉬워야 합니다.

b. 더 많은 실제 사용 사례:

가장 직접적인 확장 외에도, 제로 지식 머신 러닝, 데이터 분석 등 더 흥미로운 사용 사례가 가능해질 것입니다. Cairo와 같은 특정 ZK 언어에 비해 Rust/C++의 기능은 더 보편적이고 강력하여, 더 많은 web2 사용 사례가 Risc0 VM에서 실행될 것입니다.

c. 더 포용적이고 성숙한 개발자 커뮤니티:

STARK와 블록체인에 관심이 있는 개발자는 DSL을 다시 배울 필요 없이 Rust/C++를 사용할 수 있습니다.