원래 제목: 안전하고 효율적인 zkVM으로 가는 길: 진행 상황을 추적하는 방법

원래 저자: a16z crypto

원래 번역: Golem, Odaily Planet Daily

zkVM(제로 지식 가상 머신)은 "SNARK를 민주화"하여 누구나(전문적인 SNARK 전문 지식이 없는 사람도 포함) 주어진 입력(또는 증인)에서 모든 프로그램을 올바르게 실행했다는 것을 증명할 수 있도록 할 것을 약속합니다. 그들의 핵심 강점은 개발자 경험에 있지만, 현재 그들은 보안과 성능 측면에서 큰 과제에 직면해 있습니다. zkVM 비전이 약속한 대로 실현되려면 설계자는 이러한 과제를 극복해야 합니다. 이 글에서는 완료까지 몇 년이 걸릴 zkVM 개발의 여러 단계를 개략적으로 설명했습니다.

과제

보안 측면에서 zkVM은 매우 복잡한 소프트웨어 프로젝트이며 여전히 취약점이 많습니다. 성능 측면에서 프로그램이 올바르게 실행되는지 확인하는 데는 기본적으로 실행하는 것보다 수십만 배나 더 느릴 수 있으므로 현재로선 대부분의 애플리케이션을 현실 세계에 배포하는 것이 불가능합니다.

이러한 현실적인 어려움에도 불구하고 블록체인 산업의 대부분 회사는 zkVM을 즉시 배포할 수 있는 것으로 묘사합니다. 실제로 일부 프로젝트는 이미 체인상 활동 증명을 생성하기 위해 상당한 컴퓨팅 비용을 지불했습니다. 하지만 zkVM은 아직 불완전하기 때문에, 이는 실제로는 권한으로 보호되거나, 더 나쁜 경우, 공격에 취약한 시스템이 SNARK로 보호되고 있다고 가장하는 값비싼 방법일 뿐입니다.

안전하고 성능이 뛰어난 zkVM을 구현하기까지는 아직 몇 년이 걸릴 것입니다. 이 게시물에서는 zkVM 진행 상황을 추적하기 위한 일련의 구체적이고 단계적인 목표를 제안합니다. 이러한 목표는 과대광고를 뚫고 커뮤니티가 실제 진행 상황에 집중할 수 있도록 돕습니다.

보안 단계

SNARK 기반 zkVM은 일반적으로 두 가지 주요 구성 요소로 구성됩니다.

· 다항식에 대한 대화형 오라클 증명(PIOP): 다항식(또는 다항식에서 파생된 제약 조건)에 대한 진술을 증명하기 위한 대화형 증명 프레임워크입니다.

· 다항식 약속 체계(PCS): 증명자가 다항식의 평가에 대해 거짓말을 할 수 없도록 보장합니다.

zkVM은 기본적으로 유효한 실행 추적을 제약 조건 시스템으로 인코딩합니다. 즉, 가상 머신이 레지스터와 메모리를 올바르게 사용하도록 강제한다는 의미입니다. 그런 다음 SNARK를 적용하여 이러한 제약 조건이 충족되는지 증명합니다.

zkVM과 같은 복잡한 시스템이 버그가 없음을 보장하는 유일한 방법은 공식 검증을 통해서입니다. 보안 단계에 대한 세부 내용은 다음과 같습니다. 1단계에서는 올바른 프로토콜에 초점을 맞추고, 2단계와 3단계에서는 올바른 구현에 초점을 맞춥니다.

보안 단계 1: 올바른 프로토콜

1. PIOP의 건전성에 대한 공식 검증 증명;

2. PCS가 특정 암호화 가정 또는 이상적 모델에 따라 구속력이 있다는 공식 검증 증명;

3. Fiat-Shamir를 사용하는 경우 PIOP와 PCS를 결합하여 얻은 간결한 논증이 랜덤 오라클 모델에서 안전하다는 공식 검증 증명(필요에 따라 다른 암호화 가정으로 보강);

4. PIOP가 적용한 제약 시스템이 VM의 의미와 동일하다는 공식 검증 증명;

5. 위의 모든 부분을 단일의 공식 검증된 안전한 SNARK 증명으로 포괄적으로 "접착"하여 VM 바이트코드에서 지정한 모든 프로그램을 실행하는 데 사용할 수 있습니다. 프로토콜이 제로 지식(zero-knowledge)을 달성하려면 이 속성도 공식적으로 검증하여 증인에 대한 민감한 정보가 유출되지 않도록 해야 합니다.

재귀 경고: zkVM이 재귀를 사용하는 경우 이 단계가 완료된 것으로 간주되려면 해당 재귀에 포함된 모든 PIOP, 커밋먼트 체계 및 제약 시스템을 검증해야 합니다.

보안 단계 2: 올바른 검증기 구현

형식적 검증은 zkVM 검증기의 실제 구현(Rust, Solidity 등)이 단계 1에서 검증된 프로토콜과 일치함을 증명합니다. 이를 달성하면 구현된 프로토콜이 건전한 프로토콜인지(단순히 종이에 적은 설계나 린 방식으로 작성된 비효율적인 사양이 아닌지) 확인할 수 있습니다.

2단계가 검증자 구현에만 초점을 맞추고 증명자 구현에는 초점을 맞추지 않는 데에는 두 가지 이유가 있습니다. 첫째, 검증 도구를 올바르게 사용하면 건전성을 보장하는 데 충분합니다(즉, 검증 도구가 거짓 진술이 실제로 사실이라고 믿을 수 없도록 보장하는 것입니다). 두 번째로, zkVM 검증기 구현은 증명기 구현보다 훨씬 간단합니다.

보안 단계 3: 올바른 증명자 구현

zkVM 증명자의 실제 구현은 단계 1과 2에서 검증된 증명 시스템에 대한 증명을 올바르게 생성합니다. 즉, 형식적으로 검증됩니다. 이를 통해 완전성이 보장됩니다. 즉, zkVM을 사용하는 모든 시스템은 증명할 수 없는 진술에 "갇히지" 않습니다. 증명자가 영지식을 달성하려면 이 속성을 공식적으로 검증해야 합니다.

예상 일정

· 1단계 진행 상황:내년에 점진적인 성과(예: ZKLib)를 기대할 수 있습니다. 하지만 어떤 zkVM도 최소 2년 동안은 1단계의 요구 사항을 충족하지 못할 것입니다.

· 2단계 및 3단계: 이러한 단계는 1단계의 일부 측면과 병행하여 진행될 수 있습니다. 예를 들어, 일부 팀은 Plonk 검증기 구현이 논문의 프로토콜과 일치한다는 것을 입증했습니다(논문의 프로토콜 자체가 완전히 검증되지 않았더라도). 그래도 저는 4년 안에, 그리고 아마도 그보다 더 오래 안에 zkVM이 3단계에 도달할 것이라고 기대하지 않습니다.

주요 참고 사항: Fiat-Shamir 보안 및 검증된 바이트코드

가장 큰 문제는 Fiat-Shamir 변환의 보안을 둘러싼 해결되지 않은 연구 문제가 있다는 것입니다. 세 단계 모두 Fiat-Shamir와 무작위 오라클을 침입 불가능한 보안의 일부로 간주하지만 실제로는 패러다임 전체에 취약점이 있을 수 있습니다. 이는 이상화된 무작위 오라클과 실제로 사용되는 해시 함수 사이의 불일치로 인해 발생합니다. 최악의 경우, 2단계에 도달한 시스템이 나중에 피아트-샤미르 문제로 인해 완전히 안전하지 않은 것으로 밝혀질 수도 있습니다. 이로 인해 심각한 우려가 제기되었고 연구가 계속 진행되고 있습니다. 이런 유형의 취약점을 더 잘 방지하기 위해 변환 자체를 수정해야 할 수도 있습니다.

재귀가 없는 시스템은 일부 알려진 공격이 재귀적 증명에 사용된 것과 유사한 회로를 포함하기 때문에 이론적으로 더 견고합니다.

또 다른 주의점은 바이트코드에 명시된 대로 컴퓨터 프로그램이 올바르게 실행되었다는 것을 증명하는 것은 바이트코드 자체에 결함이 있는 경우 가치가 제한적이라는 것입니다. 따라서 zkVM의 유용성은 공식적으로 검증된 바이트코드를 생성하는 방법에 크게 좌우되는데, 이는 이 논문의 범위를 넘어서는 큰 과제입니다.

양자 이후 보안에 대하여

적어도 앞으로 5년(아마도 그 이상) 동안 양자 컴퓨터는 심각한 위협이 되지 않을 것이지만, 취약성은 존재적 위험입니다. 따라서 이제는 이 글에서 다루는 보안 및 성능 단계를 충족하는 데 주로 초점을 맞춰야 합니다. 비양자 보안 SNARK를 사용하여 이러한 보안 요구 사항을 더 빨리 충족할 수 있다면, 양자 이후 SNARK가 따라잡을 때까지 이를 수행해야 하며, 사람들이 다른 옵션을 고려하기 전에 암호학적으로 관련 있는 양자 컴퓨터에 대해 심각하게 우려하게 되어야 합니다.

ZkVM 성능 상태

현재 zkVM 증명자가 부담하는 오버헤드 요인은 네이티브 실행 비용의 약 100만 배에 가깝습니다. 여기서 프로그램을 실행하는 데 X 사이클이 걸린다면, 올바른 실행을 증명하는 데 드는 비용은 약 X배 100만 개의 CPU 사이클입니다. 이런 일은 1년 전에도 있었고, 지금도 여전히 그렇습니다.

대중적인 이야기에서는 이러한 지출이 허용되는 것처럼 들리는 방식으로 묘사되는 경우가 많습니다. 예를 들어: · "모든 Ethereum 메인넷에 대한 증명을 생성하는 데 드는 비용은 연간 100만 달러 미만입니다." · "수십 개의 GPU 클러스터를 사용하여 거의 실시간으로 Ethereum 블록 증명을 생성할 수 있습니다." · "최신 zkVM은 이전 모델보다 1000배 빠릅니다." · 이러한 주장은 기술적으로는 정확하지만 적절한 맥락이 없으면 오해의 소지가 있습니다. 예를 들어:

· 기존 zkVM보다 1000배 빠르지만 절대적인 측면에서는 여전히 매우 느립니다. 그건 상황이 얼마나 좋은지보다 얼마나 나쁜지를 더 잘 말해줍니다.

· 이더리움 메인넷이 처리할 수 있는 계산량을 10배 늘리자는 제안이 있었습니다. 이로 인해 현재 zkVM 성능이 더 느려질 것입니다.

· 사람들이 "이더리움 블록에 대한 거의 실시간 지분 증명"이라고 부르는 것은 여전히 많은 블록체인 애플리케이션이 요구하는 것보다 훨씬 느립니다(예를 들어, Optimism의 2초 블록 시간은 이더리움의 12초 블록 시간보다 훨씬 빠릅니다).

· "오류 없이 수십 개의 GPU가 항상 실행"되는 방식으로는 허용 가능한 활성 상태를 보장할 수 없습니다.

· 이더리움 메인넷에서 모든 활동을 증명하는 데 드는 비용은 연간 100만 달러 미만입니다. 이는 이더리움 전체 노드가 계산을 수행하는 데 드는 비용이 연간 약 25달러에 불과하다는 사실을 반영합니다.

블록체인 외의 애플리케이션의 경우 이러한 오버헤드는 당연히 너무 높습니다. 아무리 많은 병렬화나 엔지니어링을 수행하더라도 이렇게 엄청난 오버헤드를 상쇄할 수는 없습니다. zkVM의 기본 기준선은 네이티브 실행보다 100,000배 느리지 않아야 합니다. 이는 첫 단계에 불과하더라도 마찬가지입니다. 진정한 주류 채택에는 10,000배 이하의 오버헤드가 필요할 가능성이 높습니다.

성과 측정 방법

SNARK 성과는 세 가지 주요 구성 요소로 구성됩니다.

· 기본 증명 시스템의 본질적인 효율성.

· 애플리케이션별 최적화(예: 사전 컴파일).

· 엔지니어링 및 하드웨어 가속(예: GPU, FPGA 또는 멀티코어 CPU).

마지막 두 가지는 실제 배포에 필수적이지만 일반적으로 모든 증명 시스템에 적용되므로 반드시 기본적인 오버헤드를 반영하지는 않습니다. 예를 들어, zkEVM에 GPU 가속과 사전 컴파일 기능을 추가하면 사전 컴파일 기능 없이 순수 CPU 기반 방식보다 50배 빠른 속도를 쉽게 얻을 수 있습니다. 이는 본질적으로 효율성이 떨어지는 시스템도 그렇게 세련되지 않은 시스템보다 더 뛰어나게 보이기에 충분한 수준입니다.

따라서 다음에서는 특수 하드웨어와 사전 컴파일 없이 SNARK의 성능에 초점을 맞춥니다. 이것은 일반적으로 세 가지 요소를 모두 단일 "헤드라인 숫자"로 통합하는 현재의 벤치마킹 방법론과 다릅니다. 이는 다이아몬드의 가치를 본래의 투명도가 아닌 연마하는 데 걸린 시간에 따라 판단하는 것과 같습니다. 우리의 목표는 범용 검증 시스템의 내재적 오버헤드를 제거하여 커뮤니티가 불필요한 요소를 제거하고 검증 시스템 설계의 실질적인 진전에 집중할 수 있도록 돕는 것입니다.

성과 단계

아래는 성과 달성을 위한 5가지 이정표입니다. 첫째, CPU의 검증자 오버헤드를 몇 배나 줄여야 합니다. 그런 다음에야 하드웨어를 통한 추가 절감에 초점을 맞춰야 합니다. 메모리 사용량도 개선되어야 합니다.

다음의 모든 단계에서 개발자는 필요한 성능을 달성하기 위해 zkVM 기반의 사용자 지정 코드를 설정할 필요가 없습니다. 개발자 경험은 zkVM의 가장 큰 장점입니다. 성능 벤치마크를 충족하기 위해 DevEx를 희생한다면 zkVM 자체의 목적이 달성되지 않습니다.

이러한 측정 항목은 검증자 비용에 초점을 맞춥니다. 그러나 무제한 검증자 비용이 허용되는 경우(즉, 증명 크기나 검증 시간에 상한이 없는 경우)에는 모든 증명자 지표를 쉽게 충족할 수 있습니다. 따라서 시스템이 설명된 단계를 준수하려면 검증 크기와 검증 시간에 대한 최대값을 지정해야 합니다.

성능 요구 사항

1단계 요구 사항: "합리적이고 사소하지 않은 검증 비용":

· 증명 크기: 증명 크기는 증인 크기보다 작아야 합니다.

· 검증 시간: 증명을 검증하는 데 걸리는 시간은 프로그램을 기본적으로 실행하는 것(즉, 정확성 증명 없이 계산을 수행하는 것)보다 느려서는 안 됩니다.

이것은 단순성을 위한 최소한의 요구 사항입니다. 그들은 증거의 크기와 검증 시간이 증인을 검증자에게 보내고 검증자가 직접 정확성을 확인하는 것보다 나쁘지 않다는 것을 보장합니다.

2단계 이상 요구 사항:

· 최대 증명 크기: 256KB.

· 최대 검증 시간: 16밀리초.

이러한 제한은 더 높은 검증 비용이 발생할 수 있는 새로운 빠른 증명 기술을 수용하기 위해 의도적으로 크게 설정됩니다. 동시에 그들은 너무 비용이 많이 들기 때문에 소수의 프로젝트만이 블록체인에 포함시키려는 증명은 제외합니다.

속도 단계 1

단일 스레드 증명은 사전 컴파일에 의존하지 않고도 다양한 애플리케이션(이더리움 블록 증명에만 국한되지 않음)에서 측정했을 때 기본 실행보다 최대 100,000배 느려야 합니다.

이를 좀 더 이해하기 쉽게 설명하자면, 최신 노트북에서 초당 약 30억 사이클로 실행되는 RISC-V 프로세스를 상상해 보세요. 1단계를 달성하면 동일한 노트북에서 초당 약 30,000개의 RISC-V 사이클(단일 스레드)을 시연할 수 있다는 의미입니다. 하지만 검증 비용은 위에서 언급한 대로 "합리적이고 사소하지 않아야" 합니다.

속도 단계 2

단일 스레드 증명은 네이티브 실행보다 최대 10,000배 느려야 합니다.

또는 일부 유망한 SNARK 접근 방식(특히 바이너리 필드 기반)이 현재 CPU 및 GPU의 방해를 받기 때문에 다음을 비교하여 FPGA(또는 ASIC)를 사용하여 이 단계에 도달할 수 있습니다.

FPGA가 기본 속도로 에뮬레이션할 수 있는 RISC-V 코어 수;

RISC-V의 (거의) 실시간 실행을 시뮬레이션하고 증명하는 데 필요한 FPGA 수.

후자가 전자보다 최대 10,000배 많으면 2단계에 진출할 수 있습니다. 표준 CPU에서는 증명 크기는 최대 256KB여야 하며 검증 시간은 최대 16밀리초여야 합니다.

속도 단계 3

속도 단계 2에 도달하는 것 외에도 자동 합성과 형식적 검증의 사전 컴파일을 사용하여 1000배 미만의 증명 오버헤드(다양한 응용 프로그램에 대해)를 달성할 수 있습니다. 본질적으로, 명령어 집합은 각 프로그램에 맞게 동적으로 사용자 정의되어 증명 속도를 높일 수 있지만, 사용하기 쉽고 공식적으로 검증하기 쉬운 방식입니다.

메모리 단계 1

단계 1의 속도는 증명자에 대해 2GB 미만의 메모리를 요구하면서 달성되었습니다(동시에 지식 없음도 달성).

이것은 많은 모바일 기기나 브라우저에 매우 중요하기 때문에 수많은 클라이언트 측 zkVM 사용 사례가 생겨납니다. 고객 증명이 중요한 이유는 휴대전화가 우리를 현실 세계와 끊임없이 연결해 주기 때문입니다. 휴대전화는 우리의 위치, 자격 증명 등을 추적합니다. 증명을 생성하는 데 1-2GB 이상의 메모리가 필요하다면 오늘날 대부분의 모바일 기기에는 너무 많은 것입니다. 두 가지 사항을 명확히 해야 합니다.

· 2GB 공간 제한은 대규모 명령문(로컬에서 실행하는 데 수조 개의 CPU 주기가 필요한 명령문)에 적용됩니다. 작은 문장에만 공간 경계를 구현하는 증명 시스템은 광범위하게 적용할 수 없습니다.

· 검증자가 매우 느린 경우 검증자 메모리 크기를 2GB 이하로 유지하는 것이 쉽습니다. 따라서 메모리 단계 1을 사소하지 않게 만들기 위해 속도 단계 1이 2GB 공간 경계 내에서 충족되어야 한다고 요구했습니다.

메모리 2단계

1단계의 속도는 200MB 미만의 메모리 사용량으로 달성됩니다(메모리 1단계보다 10배 더 우수함).

2GB 이하로 낮추는 이유는 무엇인가요? 블록체인이 아닌 예를 들어보겠습니다. HTTPS를 통해 웹사이트를 방문할 때마다 인증 및 암호화를 위한 인증서를 다운로드하게 됩니다. 대신 웹사이트는 이러한 인증서를 소유하고 있다는 zk 증명을 보낼 수 있습니다. 대규모 웹사이트는 초당 수백만 개의 증명을 발행할 수도 있습니다. 각 증명을 생성하는 데 2GB의 메모리가 필요하다면 총 PB의 RAM이 필요합니다. 블록체인이 아닌 배포의 경우 메모리 사용량을 더욱 줄이는 것이 중요합니다.

사전 컴파일: 마지막 마일인가, 아니면 버팀목인가?

zkVM 디자인에서 사전 컴파일은 Keccak/SHA 해싱이나 디지털 서명을 위한 타원 곡선 그룹 연산과 같은 특정 기능에 맞게 조정된 특수 SNARK(또는 제약 시스템)를 의미합니다. 이더리움(대부분의 힘든 작업이 머클 해싱과 서명 확인과 관련됨)에서는 몇 가지 수작업으로 사전 컴파일을 수행하면 증명자 오버헤드를 줄일 수 있습니다. 하지만 그것을 지팡이처럼 의지한다면 SNARK를 필요한 곳에 도달시킬 수 없습니다. 이유는 다음과 같습니다. · 대부분 애플리케이션(블록체인 내부 및 외부 모두)에 여전히 너무 느림: 해시 및 서명 사전 컴파일을 사용하더라도 현재 zkVM은 핵심 증명 시스템의 비효율성으로 인해 여전히 너무 느립니다(블록체인 환경 내부 및 외부 모두).

· 보안 실패:공식적으로 검증되지 않은 직접 작성한 사전 컴파일은 치명적인 보안 실패로 이어질 수 있는 버그가 가득할 가능성이 매우 높습니다.

· 개발자 경험의 부족: 오늘날 대부분의 zkVM에서 새로운 사전 컴파일을 추가하려면 각 기능에 대한 제약 시스템을 수동으로 작성해야 합니다. 기본적으로 1960년대 스타일의 워크플로로 돌아가는 것입니다. 기존의 사전 컴파일이 있는 경우에도 개발자는 각 사전 컴파일을 호출하기 위해 코드를 리팩토링해야 합니다. 점진적인 성능을 추구하면서 보안과 개발자 경험을 희생해서는 안 되며, 이를 위해 최적화해야 합니다. 그렇게 하면 성능이 최상이 아니라는 것이 증명될 뿐입니다.

· I/O 오버헤드 및 RAM 없음: 사전 컴파일은 암호화 중심 작업의 성능을 향상시킬 수 있지만, 입출력을 전달할 때 상당한 오버헤드가 발생하고 RAM을 사용할 수 없기 때문에 더 다양한 작업 부하에서는 의미 있는 속도 향상을 제공하지 못할 수 있습니다. 블록체인 맥락에서도 이더리움과 같은 일체형 L1을 넘어서면(예: 일련의 크로스 체인 브리지를 구축하려는 경우) 다양한 해시 함수와 서명 체계에 직면하게 됩니다. 문제가 발생할 때마다 반복적으로 사전 컴파일을 수행하면 확장성이 떨어지고 엄청난 보안 위험을 초래할 수 있습니다.

이러한 모든 이유로 우리의 첫 번째 우선순위는 기본 zkVM의 효율성을 개선하는 것이어야 합니다. 최고의 zkVM을 만들어내는 동일한 기술이 최고의 사전 컴파일러도 만들어냅니다. 저는 사전 컴파일이 장기적으로도 필수적인 요소로 남을 것이라고 믿지만, 이는 사전 컴파일이 자동으로 합성되고 공식적으로 검증되는 경우에만 가능합니다. 이런 식으로 zkVM의 개발자 경험 이점은 그대로 유지되고 심각한 보안 위험도 피할 수 있습니다. 이런 관점은 속도 단계 3에 반영됩니다.

예상 타임라인

올해 말에 몇몇 zkVM이 속도 단계 1과 메모리 단계 1에 도달할 것으로 예상합니다. 저는 우리가 앞으로 2년 안에 Speed Phase 2에 도달할 것이라고 생각하지만, 아직 나오지 않은 새로운 아이디어 없이는 거기까지 도달할 수 있을지는 불분명합니다. 나머지 단계(스피드 단계 3과 메모리 단계 2)를 달성하는 데는 몇 년이 걸릴 것으로 예상합니다.

요약

이 게시물에서는 zkVM 보안 및 성능 단계를 별도로 식별했지만 zkVM의 이러한 측면은 완전히 독립적이지 않습니다. zkVM에서 더 많은 취약점이 발견됨에 따라, 일부는 성능이 크게 저하되면서만 수정될 것으로 예상됩니다. zkVM이 안전한 2단계에 도달할 때까지 성능을 중단해야 합니다.

zkVM은 제로 지식 증명을 진정으로 보편화할 수 있는 잠재력을 가지고 있지만 아직 초기 단계에 있으며 보안 문제와 엄청난 성능 오버헤드가 문제입니다. 과장된 광고와 마케팅 선전으로 인해 실제 진행 상황을 평가하기 어렵습니다. 명확한 안전 및 성과 이정표를 제시함으로써 방해 요소를 제거하기 위한 로드맵을 제공하고자 합니다. 우리는 목표에 도달할 것입니다. 그러나 시간과 지속적인 노력이 필요할 것입니다.

원본 링크