IOSG: zkVM과 zkEVM 간의 파벌 분쟁에 대한 다차원적 분석

저자: Bryan, IOSG Ventures

지난 2022년에는 롤업에 대한 논의의 주요 초점이 ZkEVM에 있는 것 같지만 ZkVM도 또 다른 확장 수단이라는 것을 잊지 마십시오. ZkEVM이 이 기사의 초점은 아니지만 몇 가지 측면에서 ZkVM과 ZkEVM의 차이점을 기억할 가치가 있습니다.

• 호환성: 모두 확장이지만 초점이 다릅니다.ZkEVM의 초점은 기존 EVM과의 호환성을 직접 달성하는 반면 ZkVM의 포지셔닝은 완전한 확장을 달성하는 것, 즉 dapp의 논리와 성능을 최적화하는 것입니다. 호환성이 기본이 아닙니다. 하단 레이어가 설정되면 EVM 호환성도 달성할 수 있습니다.

• 성능: 둘 다 비교적 예측 가능한 성능 병목 현상이 있습니다.ZkEVM의 주요 병목 현상은 EVM과의 호환성으로 ZK 증명 시스템에서 생성되는 추가 비용을 캡슐화하는 데 적합하지 않습니다. ZkVM의 병목 현상은 명령어 세트 ISA의 도입으로 인해 최종 출력에 대한 제약이 더 복잡하다는 것입니다.

• 개발자 경험: Type II ZkEVM(예: Scroll, Taiko)은 EVM Bytecode와의 호환성에 중점을 둡니다.즉, Bytecode 수준 이상의 EVM 코드는 ZkEVM을 통해 해당 영지식 증명을 생성할 수 있습니다. ZkVM의 경우 두 가지 방향이 있는데 하나는 자체 DSL(예: Cairo)을 만드는 것이고 다른 하나는 C++/Rust(예: Risc 0)와 같은 기존 성숙한 언어와 호환되도록 하는 것입니다. 미래에는 기본 견고성 이더리움 개발자가 ZkEVM으로 무료로 마이그레이션할 수 있고 더 새롭고 강력한 애플리케이션이 ZkVM에서 실행될 것으로 기대합니다.

많은 사람들이 이 그림을 아직도 기억하고 있을 것입니다.CairoVM은 그 자체와는 아무런 관련이 없습니다.ZkEVM 파벌 투쟁과 분리되는 근본적인 이유는 디자인 아이디어의 차이입니다.

ZkVM에 대해 논의하기 전에 가장 먼저 생각하는 것은 블록체인에서 ZK 증명 시스템을 구현하는 방법입니다. 일반적으로 회로를 구현하는 방법에는 회로 기반 시스템(회로 기반)과 가상 머신 기반 시스템(vm 기반)의 두 가지 접근 방식이 있습니다.

우선 회로 기반 시스템의 기능은 프로그램을 직접 제약 조건으로 변환하여 증명 시스템으로 보내는 것이고, 가상 머신 기반 시스템은 명령어 세트(ISA)를 통해 프로그램을 실행하고 프로세스에서 생성 실행 추적. 그런 다음 이 실행 궤적을 제약 조건에 매핑한 다음 증명 시스템에 입력합니다.

회로 기반 시스템의 경우 프로그램 계산은 프로그램을 실행하는 각 기계에 의해 제한됩니다. 가상 머신 기반 시스템의 경우 ISA는 회로 생성기에 내장되어 프로그램 제약을 생성하지만 동시에 회로 생성기는 명령어 세트, 작동 주기 및 메모리와 같은 제한 사항이 있습니다. 가상 머신은 일반성을 제공합니다. 즉, 프로그램의 작동 조건이 위에서 언급한 제한 내에 있는 한 모든 머신이 프로그램을 실행할 수 있습니다.

이미지 설명

이미지 크레디트: Bryan, IOSG Ventures

장점과 단점:

• 개발자의 관점에서 회로 기반 시스템에서 개발하려면 종종 각 제약 조건의 비용에 대한 깊은 이해가 필요합니다. 그러나 가상 머신 프로그램을 작성하는 경우 회로는 정적이며 개발자는 지침에 더 신경을 써야 합니다.

• 검증자의 관점에서, 회로 기반 시스템과 가상 머신은 동일한 순수 SNARK가 백엔드로 사용된다고 가정할 때 회로의 일반성에서 크게 다릅니다. 회로 시스템은 각 프로그램에 대해 서로 다른 회로를 생성하는 반면 가상 머신은 서로 다른 프로그램에 대해 동일한 회로를 생성합니다. 이는 롤업에서 회로 시스템이 L1에 여러 검증자 계약을 배포해야 함을 의미합니다.

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

• 시스템 복잡도(complexity)의 관점에서 볼 때, 가상 머신은 단순한 회로 시스템에 비해 메모리 모델, 호스트(호스트)와 클라이언트(게스트) 간의 통신 등과 같이 시스템에 더 많은 복잡성을 통합합니다.

이미지 설명

첫 번째 레벨 제목

가상 머신 설계 원칙

보조 제목

1. ISA 명령어 세트

회로 생성기의 작동 방식을 지정합니다. 주요 책임은 지침을 제약 조건에 올바르게 매핑한 다음 증명 시스템에 공급하는 것입니다. zk 시스템은 RISC(Reduced Instruction Set)를 사용합니다. 두 가지 ISA 선택 사항이 있습니다.

첫 번째는 카이로의 디자인에서 볼 수 있는 맞춤형 ISA(custom ISA)를 구축하는 것이다. 일반적으로 다음과 같은 네 가지 유형의 제약 논리가 있습니다.

사용자 지정 ISA의 기본 설계 초점은 프로그램 실행과 확인이 모두 빠르게 실행되도록 가능한 한 적은 제약이 있는지 확인하는 것입니다.

보조 제목

2. 컴파일러

대체로 컴파일러는 프로그래밍 언어를 점차 기계 코드로 변환합니다. ZK의 맥락에서 C, C++, Rust 등과 같은 고급 언어를 사용하여 제약 시스템(R 1 CS, QAP, AIR 등)으로 컴파일된 저급 코드 표현을 말합니다. 두 가지 방법이 있습니다.

• 기존 zk 회로 표현을 기반으로 컴파일러를 설계합니다. 예를 들어 ZK에서 회로 표현은 Bellman과 같은 직접 호출 가능한 라이브러리와 Circcom과 같은 저수준 언어에서 시작됩니다. 다양한 표현을 통합하기 위해 Zokrates(그 자체가 DSL)와 같은 컴파일러는 임의의 하위 수준 표현으로 컴파일할 수 있는 추상화 계층을 제공하는 것을 목표로 합니다.

• (기존) 컴파일러 인프라를 구축합니다. 기본 논리는 여러 프런트엔드 및 백엔드에 대한 중간 표현을 활용하는 것입니다.

Risc 0 컴파일러는 다중 IR(LLVM과 유사)을 생성할 수 있는 다중 레벨 중간 표현(MLIR)을 기반으로 합니다. 다양한 IR은 개발자에게 유연성을 제공합니다. 예를 들어 IR 중 일부는 하드웨어에 맞게 최적화되어 있어 개발자가 원하는 대로 선택할 수 있습니다. GCC를 사용하는 vnTinyRAM 및 TinyRAM에서도 유사한 아이디어를 볼 수 있습니다. ZkSync는 컴파일러 인프라를 악용하는 또 다른 예입니다.

또한 LLVM에서 일부 설계 개념을 차용한 CirC와 같은 zk용 일부 컴파일러 인프라도 볼 수 있습니다.

위의 두 가지 가장 중요한 설계 단계 외에도 몇 가지 다른 고려 사항이 있습니다.

1. 시스템 보안(security)과 검증 비용(verifier cost) 사이의 trade-off

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

2. 프런트엔드 및 백엔드와의 호환성

호환성은 회로에 대한 중간 표현의 가용성에 따라 달라집니다. IR은 정확성(프로그램의 출력이 입력과 일치하는지 + 출력이 증명 시스템과 일치하는지)과 유연성(여러 프런트엔드 및 백엔드 지원) 사이에서 균형을 유지해야 합니다. IR이 원래 R 1 CS 와 같은 낮은 수준의 제약이 있는 시스템을 해결하도록 설계된 경우 AIR와 같은 다른 높은 수준의 제약이 있는 시스템과의 호환성은 어렵습니다.

3. 효율성을 높이려면 손으로 만든 회로가 필요합니다.

범용 모델을 사용할 때의 단점은 복잡한 명령이 필요하지 않은 일부 간단한 작업에 덜 효율적이라는 것입니다.

이전 이론 중 일부를 간략하게 설명하면,

• 피노키오 프로토콜 이전: 검증 가능한 계산이 달성되었지만 검증 시간이 매우 느림

• 피노키오 프로토콜 : 검증가능성과 검증성공률 측면에서 이론적 타당성을 제공하며(즉, 검증시간이 프로그램 수행시간보다 짧음), 회로 기반 시스템

• TinyRAM 프로토콜: Pinocchio 프로토콜과 비교할 때 TinyRAM은 가상 머신에 가깝고 ISA를 도입하므로 메모리 액세스(RAM), 제어 흐름(제어 흐름) 등과 같은 일부 제한이 제거됩니다.

• vnTinyRAM 프로토콜: 각 프로그램과 독립적으로 키를 생성하여 추가적인 다양성을 제공합니다. 확장 회로 생성기, 즉 더 큰 프로그램을 처리할 수 있습니다.

위의 모델들은 모두 SNARK를 백엔드 증명 시스템으로 사용하지만 특히 가상 머신을 다룰 때 STARK와 Plonk가 더 적합한 백엔드인 것 같습니다.

다음으로 이 기사에서는 3개의 STARK 기반 가상 머신(Risc 0, MidenVM, CairoVM)을 소개합니다. 요컨대, STARK를 증명 시스템으로 사용하는 것과는 별개로 각각 몇 가지 차이점이 있습니다.

• Risc 0은 명령어 세트의 단순성을 위해 Risc-V를 활용합니다. R 0은 Rust, C++와 같은 기존의 여러 범용 프로그래밍 언어를 지원하도록 설계된 LLVM-IR의 변형인 MLIR로 컴파일됩니다. Risc-V는 또한 하드웨어에 더 친숙하다는 것과 같은 몇 가지 추가 이점이 있습니다.

• Miden은 본질적으로 EVM의 롤업인 Ethereum Virtual Machine(EVM)과 호환되는 것을 목표로 합니다. 현재 Miden은 자체 프로그래밍 언어를 보유하고 있지만 향후 Move를 지원하기 위해 노력하고 있습니다.

• Cairo VM은 Starkware에서 개발했습니다. 이 세 가지 시스템에서 사용하는 STARK 증명 시스템은 현재 Starkware의 사장인 Eli Ben-Sasson이 발명했습니다.

차이점을 자세히 살펴보겠습니다.

* 위의 양식은 어떻게 읽나요? 메모 좀...

• 워드 크기 - 이러한 가상 머신이 기반으로 하는 제약 시스템은 AIR이므로 CPU 아키텍처와 유사하게 작동합니다. 따라서 CPU 워드 길이(32/64비트)를 선택하는 것이 더 적절합니다.

• 메모리 액세스(메모리 읽기) - Risc 0이 레지스터를 사용하는 이유는 주로 Risc-V 명령어 세트가 레지스터를 기반으로 하기 때문입니다. AIR는 스택처럼 작동하므로 Miden은 주로 스택을 사용하여 데이터를 저장합니다. CairoVM은 Cairo 모델에서 메모리 액세스(메인 메모리) 비용이 저렴하기 때문에 범용 레지스터를 사용하지 않습니다.

• 프로그램 피드(프로그램 실행) - 다른 방법에는 장단점이 있습니다. 예를 들어 마스트 루트 방식의 경우 명령어를 처리할 때 디코딩을 해야 하므로 단계가 많은 프로그램에서 증명 비용이 많이 든다.

• 부트로딩 접근 방식은 프라이버시를 유지하면서 증명자 비용과 검증자 비용 사이의 균형을 맞추려고 시도합니다.

• 비결정론 - 비결정론은 NP-완전 문제의 중요한 속성입니다. 비결정론을 활용하면 과거 실행을 빠르게 확인할 수 있습니다. 차례로 더 많은 제약 조건을 추가하므로 유효성 검사에 약간의 타협이 있습니다.

• 복잡한 작업의 가속화 - 일부 계산은 CPU에서 매우 느리게 실행됩니다. 예를 들어, XOR 및 AND와 같은 비트 연산, ECDSA와 같은 해시 프로그램, 범위 확인... 대부분 블록체인/암호화폐에 고유하지만 CPU 고유 연산은 아닙니다(비트 연산 제외). DSL을 통해 이러한 작업을 직접 구현하면 쉽게 증명 주기가 고갈될 수 있습니다.

• 순열/다중 집합(순열/다중 열 조합) - 대부분의 zkVM에서 많이 사용되며 두 가지 목적이 있습니다. - 1. 전체 실행 추적(실행 추적)의 저장을 줄임으로써 검증자 비용 절감 전체 실행 추적

기사의 끝에서 저자는 Risc 0의 현재 개발과 그것이 나를 흥분시키는 이유에 대해 이야기하고 싶습니다.

R 0 현재 개발:

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

b. 필드 확장과 같은 일부 흥미로운 혁신은 보다 견고한 보안 매개변수를 달성하고 더 큰 정수에서 작동할 수 있습니다.

c. ZK Hardware와 ZK Software 회사 간의 통합에서 볼 수 있는 문제를 목격한 Risc 0은 하드웨어 측면에서 더 나은 개발을 위해 하드웨어 추상화 계층을 사용합니다.

d.아직 진행 중!아직 개발 중!

• 손으로 만든 회로와 다중 해시 알고리즘을 지원합니다. 현재 전용 SHA 256 회로가 구현되어 있지만 모든 요구 사항이 충족되지는 않습니다. 저자는 최적화할 회로의 선택이 Risc 0에서 제공하는 사용 사례에 달려 있다고 생각합니다. SHA 256은 매우 좋은 출발점입니다. 반면에 ZKVM은 예를 들어 사람들이 원하지 않는 경우 Keccak에 신경 쓰지 않도록 유연성을 제공할 수 있는 위치에 있습니다. :)

• 재귀: 이것은 거대한 주제이며 이 보고서에서 자세히 다루지 않는 경향이 있습니다. Risc 0은 더 복잡한 사용 사례/프로그램을 지원하는 경향이 있으므로 재귀의 필요성이 더 시급하다는 점에 유의하십시오. 재귀를 추가로 지원하기 위해 현재 하드웨어 측 GPU 가속 솔루션을 연구하고 있습니다.

• 비결정성 처리: 이것은 ZKVM이 처리해야 하는 속성이지만 기존 가상 머신에는 이 문제가 없습니다. 비결정성은 가상 시스템이 더 빠르게 수행하는 데 도움이 될 수 있습니다. MLIR은 기존 가상 머신 문제를 처리하는 데 상대적으로 더 좋으며 Risc 0이 ZKVM 시스템 설계에 비결정성을 포함하는 방법은 기대할 가치가 있습니다.

WHAT EXCITES ME:

A. 간단하고 검증 가능!

분산 시스템에서 PoW는 사람들이 다른 사람을 신뢰하지 않기 때문에 높은 수준의 중복성이 필요하므로 합의에 도달하기 위해 동일한 계산을 반복적으로 수행해야 합니다. 그리고 영지식 증명을 활용하여 상태 실현은 1+1=2에 동의하는 것처럼 쉬워야 합니다.

b. 보다 실용적인 사용 사례:

가장 직접적인 확장 외에도 영지식 기계 학습, 데이터 분석 등과 같은 더 흥미로운 사용 사례가 실현될 것입니다. Cairo와 같은 특정 ZK 언어와 비교할 때 Rust/C++는 더 다양하고 강력하며 더 많은 web2 사용 사례가 Risc 0 VM에서 실행됩니다.

c. 보다 포괄적이고 성숙한 개발자 커뮤니티:

STARK 및 블록체인에 관심이 있는 개발자는 DSL을 다시 배울 필요 없이 Rust/C++만 사용하면 됩니다.