a16z: zkVM의 안전하고 효율적인 구현을 단계별로 어떻게 달성할 수 있을까?
글: a16z crypto
번역: Odaily Star Daily Golem
zkVM(제로지식 가상 머신)은 "SNARK를 대중화"하겠다는 약속을 담고 있으며, 전문적인 SNARK 지식이 없는 사람이라도 주어진 입력(또는 증거) 상에서 어떤 프로그램이 올바르게 실행되었음을 증명할 수 있도록 한다. 그 핵심 이점은 개발자 경험에 있지만, 현재로서는 보안과 성능 측면에서 모두 거대한 도전에 직면해 있다. zkVM의 비전이 진정한 실현을 이루기 위해서는 설계자들이 이러한 도전들을 극복해야 한다. 본 글에서는 zkVM 개발의 가능한 단계들을 나열하며, 이를 완수하는 데에는 몇 년이 걸릴 것임을 언급한다.
도전 과제
보안 측면에서, zkVM은 여전히 버그로 가득 찬 고도로 복잡한 소프트웨어 프로젝트이다. 성능 면에서는 프로그램의 정확한 실행을 입증하는 속도가 로컬 실행보다 수십만 배 느릴 수 있어 대부분의 애플리케이션은 현재로서 현실 세계에 배포하기 어렵다.
이러한 현실적인 도전에도 불구하고, 블록체인 산업의 많은 기업들은 zkVM을 즉시 배포 가능하다고 묘사하고 있다. 실제로 일부 프로젝트들은 체인 상 활동에 대한 증명을 생성하기 위해 막대한 계산 비용을 지불하고 있다. 그러나 zkVM이 아직 완성되지 않았기 때문에, 이것은 실제로는 허가 기반으로 보호되거나 더 나쁜 경우 공격에 취약한 상태에서 SNARK로 시스템이 보호되고 있다는 것을 가장하는 값비싼 방법일 뿐이다.
우리는 안전하고 고성능의 zkVM을 구현하기까지 아직 수년이 남아 있다. 본 글은 zkVM의 진전을 추적할 수 있는 일련의 단계별 구체적인 목표를 제안함으로써 과장된 홍보를 제거하고 커뮤니티가 진정한 발전에 집중하도록 돕고자 한다.
보안 단계
SNARK 기반의 zkVM은 일반적으로 다음 두 가지 주요 구성 요소를 포함한다:
-
다항식 대화형 오라클 증명 (PIOP): 다항식(또는 이로부터 유도되는 제약 조건)에 관한 진술을 증명하기 위한 대화형 증명 프레임워크.
-
다항식 커밋 방식 (PCS): 증명자가 다항식 평가에 대해 거짓말을 하더라도 발견되지 않도록 하는 것을 방지한다.
zkVM은 본질적으로 유효한 실행 트레이스를 제약 시스템으로 인코딩하는 것이다—즉, 가상 머신이 레지스터와 메모리를 올바르게 사용하도록 강제한다는 의미이며—그 후 SNARK를 적용하여 이러한 제약 조건들이 만족됨을 증명한다.
zkVM처럼 복잡한 시스템에 오류가 없는지를 보장하는 유일한 방법은 형식적 검증체계(formal verification)이다. 아래는 보안 단계의 세부 분류이다. 1단계는 올바른 프로토콜에 초점을 맞추며, 2단계와 3단계는 올바른 구현에 집중한다.
보안 단계 1: 올바른 프로토콜
-
PIOP 신뢰성에 대한 형식적 검증 증명;
-
특정 암호학적 가정이나 이상적 모델 하에서 PCS가 바인딩(binding) 성질을 갖는다는 형식적 검증 증명;
-
Fiat-Shamir 변환이 사용될 경우, PIOP와 PCS를 결합하여 얻은 간결한 논증이 랜덤 오라클 모델 하에서 안전하다는 형식적 검증 증명(필요 시 추가 암호학적 가정을 통해 강화);
-
PIOP에 적용되는 제약 조건 시스템이 VM의 의미론과 동등하다는 형식적 검증 증명;
-
위 모든 구성 요소들을 통합하여 VM 바이트코드로 지정된 임의의 프로그램 실행에 대한 단일의, 형식적으로 검증된 안전한 SNARK 증명을 만드는 작업. 만약 프로토콜이 제로지식을 달성하려는 목적이 있다면, 증거자의 민감 정보가 노출되지 않는다는 특성 또한 형식적으로 검증되어야 한다.
재귀성 경고: 만약 zkVM이 재귀성을 사용한다면, 이 단계가 완료되었다고 보기 위해서는 재귀 내 어디에서든 사용되는 모든 PIOP, 커밋 방식 및 제약 시스템이 검증되어야 한다.
보안 단계 2: 올바른 검증기 구현
Rust, Solidity 등으로 이루어진 zkVM 검증기의 실제 구현이 1단계에서 검증된 프로토콜과 일치함을 형식적으로 검증하는 증명. 이를 달성하면 구현된 프로토콜이 타당함을 보장할 수 있다(단지 종이 위의 설계나 Lean 등으로 작성된 비효율적인 사양이 아님).
2단계가 증명기(prover)가 아닌 검증기(verifier) 구현에만 집중하는 이유는 두 가지다. 첫째, 검증기의 올바른 사용만으로도 신뢰성(reliability)—즉, 검증기가 잘못된 진술을 참으로 믿는 일이 없도록—을 보장할 수 있기 때문이다. 둘째, zkVM 검증기 구현은 증명기 구현보다 수준이 한 차원 이상 단순하다.
보안 단계 3: 올바른 증명기 구현
zkVM 증명기의 실제 구현이 1단계와 2단계에서 검증된 증명 시스템의 증명을 정확하게 생성함을 형식적으로 검증한다. 이는 완전성(integrity)을 보장하는 것으로, zkVM을 사용하는 어떤 시스템도 증명 불가능한 진술에 의해 '막히는' 상황이 없음을 의미한다. 증명기가 제로지식을 구현하려는 목적을 가지고 있다면, 해당 특성 또한 형식적으로 검증되어야 한다.
예상 일정
1단계 진행 상황: 내년에 점진적인 성과(예: ZKLib)가 기대된다. 그러나 최소 2년 이내로는 어느 zkVM도 1단계 요구사항을 완전히 충족하지 못할 것이다.
2단계 및 3단계: 이 단계들은 1단계의 일부와 동시에 진행될 수 있다. 예를 들어, 일부 팀들은 Plonk 검증기 구현이 논문의 프로토콜과 일치함을 이미 증명했다(비록 논문 자체의 프로토콜이 완전히 검증되었는지는 미확실). 그럼에도 불구하고, 어떤 zkVM도 4년 이내에 3단계에 도달하지 못할 것이며, 더 오래 걸릴 가능성도 크다고 본다.
핵심 고려사항: Fiat-Shamir 보안성과 검증된 바이트코드
주요 복잡 요인 중 하나는 Fiat-Shamir 변환의 보안성과 관련된 해결되지 않은 연구 문제들이다. 세 단계 모두 Fiat-Shamir와 랜덤 오라클을 그들의 무결한 보안성 일부로 간주하지만, 실제로는 전체 패러다임 자체에 취약점이 존재할 수 있다. 이는 랜덤 오라클이 너무 이상화된 개념이고 실제 사용되는 해시 함수 사이에 차이가 있기 때문이다. 최악의 경우, Fiat-Shamir 문제로 인해 2단계에 도달한 시스템조차도 나중에 완전히 안전하지 않다는 것이 밝혀질 수 있다. 이는 심각한 우려를 낳으며 현재도 지속적인 연구가 진행 중이다. 우리는 이러한 취약점을 더 잘 방어하기 위해 변환 자체를 수정해야 할 수도 있다.
재귀성이 없는 시스템은 이론적으로 더욱 견고하다. 왜냐하면 알려진 일부 공격들이 재귀적 증명에 사용되는 회로와 유사한 회로를 포함하기 때문이다.
또 다른 주목할 점은, 바이트코드 자체에 결함이 있다면, 컴퓨터 프로그램이 바이트코드에 따라 올바르게 실행되었다는 증명의 가치는 제한적이라는 점이다. 따라서 zkVM의 실용성은 크게 형식적으로 검증된 바이트코드를 생성하는 방법에 달려 있다—이는 본문 범위를 넘어서는 거대한 도전이다.
후기 양자 컴퓨팅 시대의 보안성에 대하여
최소 향후 5년간(더 길 수도 있음), 양자 컴퓨터는 심각한 위협이 되지 않을 것이며, 반면 버그는 생존 위험을 의미한다. 따라서 현재의 주요 초점은 본문에서 논의된 보안 및 성능 단계를 충족시키는 것이어야 한다. 우리가 비양자 안전한 SNARK를 사용하여 이러한 보안 요구를 더 빠르게 달성할 수 있다면, 후기 양자 SNARK가 따라오거나 암호학 관련 양자 컴퓨터가 등장할 가능성이 심각하게 고려되기 전까지 그렇게 해야 한다.
zkVM의 현재 성능 상태
현재 zkVM 증명기가 발생시키는 오버헤드 계수는 원본 실행 비용의 약 100만 배에 달한다. 프로그램이 X 사이클 동안 실행된다면, 올바른 실행을 증명하는 데 드는 비용은 약 X × 100만 CPU 사이클이다. 1년 전부터 지금까지 상황은 동일하다.
흔한 서사는 이러한 오버헤드를 받아들일 만한 것처럼 묘사하곤 한다. 예를 들어:
-
"모든 이더리움 메인넷 활동에 대한 증명을 생성하는 데 연간 100만 달러도 채 들지 않는다."
-
"수십 개의 GPU로 구성된 클러스터를 이용하면 거의 실시간으로 이더리움 블록 증명을 생성할 수 있다."
-
"우리의 최신 zkVM은 이전 제품보다 1000배 빠르다."
기술적으로 이러한 주장들은 정확할 수 있으나, 적절한 문맥 없이는 오도될 수 있다. 예를 들어:
-
이전 zkVM보다 1000배 빠르지만 절대적 속도는 여전히 매우 느리다. 이는 얼마나 좋았는지보다 얼마나 나빴는지를 더 잘 보여준다.
-
이미 이더리움 메인넷의 처리량을 10배 늘리는 방안이 제안된 바 있다. 이는 현재의 zkVM 성능을 더 느리게 만들 것이다.
-
사람들이 말하는 '이더리움 블록의 거의 실시간 증명'도 Optimism의 2초 블록 시간에 비해 훨씬 느리며, 많은 블록체인 애플리케이션이 요구하는 수준보다 훨씬 느리다(이더리움은 12초 블록 시간).
-
"수십 개의 GPU가 항상 오류 없이 작동한다"는 것은 수용 가능한 활성 보장을 달성하지 못한다.
-
연간 100만 달러 미만을 지불하여 이더리움 메인넷의 모든 활동을 증명한다는 것은, 이더리움 풀 노드가 매년 계산 수행에 약 25달러만 필요하다는 사실을 반영한다.
블록체인 외부의 애플리케이션의 경우, 이러한 오버헤드는 명백히 너무 높다. 어떤 병렬화나 엔지니어링도 이 정도의 오버헤드를 상쇄할 수 없다. 우리는 기본 기준으로 zkVM 속도 저하가 원본 실행 대비 10만 배 이내가 되어야 한다고 생각한다—비록 이것이 첫걸음에 불과하더라도. 진정한 대중화는 1만 배 또는 그 이하의 오버헤드에 가까워져야 가능할 것이다.
성능 측정 방법
SNARK 성능은 다음과 같은 세 가지 주요 요소로 구성된다:
-
기반 증명 시스템의 내재적 효율성.
-
애플리케이션 특정 최적화(예: 사전 컴파일).
-
엔지니어링 및 하드웨어 가속(GPU, FPGA 또는 멀티코어 CPU).
후자 두 가지는 실제 배포에 중요하지만, 일반적으로 어떤 증명 시스템에도 적용 가능하므로 반드시 기본 오버헤드를 반영하지는 않는다. 예를 들어, zkEVM에 GPU 가속과 사전 컴파일을 추가하면 쉽게 50배의 가속을 얻을 수 있는데, 이는 순수 CPU 기반의 사전 컴파일 없는 방법보다 훨씬 빠르다—그 결과 본질적으로 효율이 낮은 시스템조차도 마치 더 정교하게 다듬어진 시스템보다 낫게 보일 수 있다.
따라서 아래에서는 전용 하드웨어와 사전 컴파일 없이 SNARK의 성능에 초점을 맞춘다. 이는 일반적으로 세 가지 요소를 하나의 '주요 숫자'로 요약하는 현재의 벤치마크 방법과 다르다. 이것은 다이아몬드의 가치를 광택 시간이 아니라 본질적인 순도에 따라 판단하는 것과 같다. 우리의 목표는 일반적인 증명 시스템의 내재적 오버헤드를 제거하여 커뮤니티가 혼란 요소를 제거하고 증명 시스템 설계의 진정한 발전에 집중하도록 돕는 것이다.
성능 단계
다음은 성능 달성을 위한 5개의 이정표이다. 우선, CPU 상의 증명기 오버헤드를 여러 수준 낮춰야 한다. 그 후에야 비로소 하드웨어를 통한 추가 감소에 집중해야 한다. 메모리 사용률도 향상되어야 한다.
아래 모든 단계에서, 개발자는 zkVM 설정에 맞춰 맞춤 코드를 작성하지 않고도 필요한 성능을 달성할 수 있어야 한다. 개발자 경험은 zkVM의 주요 이점이다. 성능 기준을 충족하기 위해 DevEx를 희생하는 것은 zkVM 자체의 의미를 반박하는 것이다.
이 지표들은 증명기 비용에 중점을 둔다. 그러나 검증기 비용에 제한이 없다면(즉, 증명 크기나 검증 시간에 상한이 없다면), 어떤 증명기 지표라도 쉽게 달성할 수 있다. 따라서 설명된 단계에 부합하는 시스템은 증명 크기와 검증 시간에 대해 최댓값을 명시해야 한다.
성능 요구사항
1단계 요구사항: "합리적이며 자명하지 않은 검증 비용":
-
증명 크기: 증명 크기는 증거(witness) 크기보다 작아야 한다.
-
검증 시간: 증명 검증 속도는 프로그램을 네이티브로 실행하는 것보다 느려서는 안 된다(즉, 정확성 증명 없이 계산을 수행하는 것).
이들은 최소한의 간결성 요구사항이다. 증명 크기와 검증 시간이 증거를 검증자에게 보내 직접 확인하는 방법보다 더 나빠지지 않도록 보장한다.
2단계 및 이후 요구사항:
-
최대 증명 크기: 256KB.
-
최대 검증 시간: 16밀리초.
이 한계값들은 새로운 고속 증명 기술로 인해 더 높은 검증 비용이 발생할 수 있음을 고려하여 일부러 여유 있게 설정되었다. 동시에, 너무 비싸서 거의 어떤 프로젝트도 블록체인에 포함시키기를 꺼릴 정도의 증명은 배제한다.
속도 단계 1
단일 스레드 증명은 사전 컴파일에 의존하지 않고, 다양한 애플리케이션에서 측정했을 때 네이티브 실행보다 최대 10만 배 느려야 한다.
구체적으로, 초당 약 30억 사이클로 작동하는 현대 노트북 상의 RISC-V 프로세스를 상상해보자. 1단계를 달성한다는 것은 동일한 노트북에서 초당 약 3만 개의 RISC-V 사이클을 증명할 수 있다는 의미다(단일 스레드). 하지만 검증 비용은 앞서 언급한 바와 같이 "합리적이며 자명하지 않아야" 한다.
속도 단계 2
단일 스레드 증명은 네이티브 실행보다 최대 1만 배 느려야 한다.
또한, 일부 유망한 SNARK 방법들(특히 이진 필드 기반 방법들)은 현재의 CPU와 GPU에 의해 제약받기 때문에, FPGA(혹은 ASIC)를 사용하여 비교할 수도 있다:
-
FPGA가 네이티브 속도로 시뮬레이션할 수 있는 RISC-V 코어 수;
-
RISC-V의 시뮬레이션 및 증명을 (거의) 실시간으로 수행하는 데 필요한 FPGA 수량.
후자가 전자보다 많아야 할 경우 최대 1만 배 이하여야 2단계에 합격한다. 표준 CPU 상에서는 증명 크기가 최대 256KB, 검증 시간은 최대 16밀리초여야 한다.
속도 단계 3
속도 단계 2에 도달하는 것 외에도, 자동 합성 및 형식 검증된 사전 컴파일을 사용하여 1000배 미만의 증명 오버헤드를 달성해야 한다(광범위한 애플리케이션에 적용 가능). 본질적으로 각 프로그램마다 명령어 세트를 동적으로 맞춤화하여 증명을 가속화할 수 있지만, 사용하기 쉬우면서도 형식적으로 검증 가능한 방식이어야 한다.
메모리 단계 1
증명기에 요구되는 메모리가 2GB 미만인 상태에서 속도 단계 1을 달성해야 한다(제로지식도 함께 구현되어야 함).
이는 많은 모바일 기기나 브라우저에 매우 중요하며, 무수한 클라이언트 zkVM 용례를 열어준다. 클라이언트 측 증명은 중요하다. 우리 휴대폰은 현실 세계와의 지속적인 연결 고리이기 때문이며, 위치, 자격증명 등을 추적한다. 증명 생성에 1~2GB 이상의 메모리가 필요하다면 오늘날 대부분의 모바일 기기에서는 지나치게 많다. 두 가지를 명확히 해야 한다:
-
2GB 공간 제한은 로컬에서 수조 사이클이 소요되는 큰 진술(large statement)에 적용되어야 한다. 작은 진술에 대해서만 공간 제한을 달성한 증명 시스템은 광범위한 활용성이 부족하다.
-
증명기가 매우 느리다면, 증명기의 공간을 2GB 이하로 유지하는 것은 매우 쉽다. 따라서 메모리 단계 1이 단순하지 않도록 하기 위해, 2GB 공간 제한 내에서 속도 단계 1을 동시에 충족해야 한다.
메모리 단계 2
속도 단계 1이 메모리 사용량 200MB 미만에서 달성되어야 한다(메모리 단계 1보다 10배 우수).
왜 2GB 이하로 밀어붙이는가? 블록체인이 아닌 예를 생각해보자: HTTPS로 웹사이트에 접속할 때마다 인증 및 암호화를 위해 인증서를 다운로드한다. 대신, 웹사이트는 이러한 인증서를 소유하고 있다는 zk 증명을 보낼 수 있다. 대규모 웹사이트는 매초 수백만 개의 그러한 증명을 발행할 수 있다. 각 증명 생성에 2GB 메모리가 필요하다면, 총 RAM 요구량은 PB급이 된다. 비블록체인 배포에서는 메모리 사용량을 더욱 낮추는 것이 필수적이다.
사전 컴파일: 마지막 1마일인가, 아니면 목발인가?
zkVM 설계에서 사전 컴파일이란 Keccak/SHA 해시나 타원곡선 군 연산과 같은 특정 기능에 맞춤화된 전용 SNARK(또는 제약 시스템)을 말한다. 이더리움에서는(Merkle 해시와 서명 검사가 대부분의 무거운 작업을 차지함) 수작업으로 제작된 사전 컴파일이 증명기 오버헤드를 줄일 수 있다. 그러나 이를 목발처럼 의존하는 것은 SNARK가 도달해야 할 지점에 도달하지 못하게 한다. 그 이유는 다음과 같다:
-
대부분의 애플리케이션(블록체인 내외부 모두)에서는 여전히 너무 느림: 해시 및 서명 사전 컴파일을 사용하더라도 현재의 zkVM은 여전히 너무 느리며(블록체인 내외부 모두), 핵심 증명 시스템 자체가 비효율적이기 때문이다.
-
보안 실패: 형식 검증되지 않은 수작업 사전 컴파일은 거의 확실히 오류로 가득 차 있으며, 치명적인 보안 실패를 초래할 수 있다.
-
개발자 경험 부족: 오늘날 대부분의 zkVM에서 새로운 사전 컴파일을 추가한다는 것은 각 기능마다 수동으로 제약 시스템을 작성하는 것을 의미한다—본질적으로 1960년대 스타일의 워크플로로 돌아가는 것이다. 기존 사전 컴파일을 사용하더라도, 개발자는 각 사전 컴파일을 호출하기 위해 코드를 재구성해야 한다. 우리는 안전성과 개발자 경험을 최적화해야 하며, 증분 성능을 추구하면서 이 둘을 희생해서는 안 된다. 그렇게 하는 것은 성능이 요구되는 수준에 도달하지 못했음을 입증하는 것이다.
-
I/O 오버헤드 및 RAM 부재: 사전 컴파일은 무거운 암호화 작업의 성능을 향상시킬 수 있지만, 입력/출력 전달 시 막대한 오버헤드가 발생하고 RAM을 사용할 수 없기 때문에 더 다양한 워크로드에는 의미 있는 가속을 제공하지 못할 수 있다. 블록체인 환경 내에서도 이더리움과 같은 단일 L1을 넘어선다면(예: 일련의 크로스체인 브릿지를 구축하고자 한다면), 다른 해시 함수와 서명 방식에 직면하게 된다. 문제에 대해 반복적으로 사전 컴파일을 수행하는 것은 확장되지 않으며 막대한 보안 리스크를 초래한다.
이러한 모든 이유로, 우리의 최우선 과제는 기본 zkVM의 효율성을 높이는 것이어야 한다. 가장 좋은 zkVM 기술은 가장 좋은 사전 컴파일도 만들어낸다. 장기적으로 사전 컴파일이 여전히 중요할 것이라 믿지만, 전제는 자동 합성되고 형식 검증되어야 한다는 점이다. 이렇게 하면 zkVM의 개발자 경험 이점을 유지하면서도 치명적인 보안 리스크를 피할 수 있다. 이 관점은 속도 단계 3에 반영되어 있다.
예상 일정
소수의 zkVM이 올해 말에 속도 단계 1과 메모리 단계 1을 달성할 것이라 예상한다. 속도 단계 2는 향후 2년 내에 달성될 수 있을 것이라 생각하지만, 아직 나타나지 않은 새로운 아이디어 없이는 달성 여부가 불확실하다. 나머지 단계(속도 단계 3 및 메모리 단계 2)는 몇 년이 더 소요될 것이라 예상한다.
결론
본 글에서 zkVM의 보안성과 성능 단계를 별개로 제시했지만, 이 두 측면은 완전히 독립적이지는 않다. zkVM에서 더 많은 버그가 발견됨에 따라, 일부 버그는 성능이 크게 저하되는 경우에만 수정 가능한 것으로 나타날 수 있다. zkVM이 보안 단계 2에 도달하기 전까지는 성능은 보류되어야 한다.
zkVM은 제로지식 증명을 진정으로 대중화할 가능성을 지녔지만, 여전히 초기 단계에 있으며 보안 도전과 막대한 성능 오버헤드로 가득 차 있다. 과장과 마케팅은 진정한 진전을 평가하기 어렵게 만든다. 명확한 보안 및 성능 이정표를 제시함으로써, 방해 요소를 제거하는 로드맵을 제공하고자 한다. 우리는 목표에 도달할 것이며, 다만 시간과 지속적인 노력이 필요할 뿐이다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
a16z
