a16z crypto 의 원본 기사
Odaily Planet Daily Golem( @web3_golem ) 이 편집
zkVM(제로 지식 가상 머신)은 누구나(SNARK에 대한 전문 지식이 없는 사람도 포함) 주어진 입력(또는 증인)에서 모든 프로그램을 올바르게 실행했다는 것을 증명할 수 있도록 함으로써 SNARK를 민주화하겠다고 약속합니다. 그들의 핵심 강점은 개발자 경험에 있지만, 현재 그들은 보안과 성능 측면에서 큰 과제에 직면해 있습니다. zkVM 비전이 약속한 대로 실현되려면 설계자는 이러한 과제를 극복해야 합니다. 이 글에서는 완료까지 몇 년이 걸릴 zkVM 개발의 여러 단계를 개략적으로 설명했습니다.
도전
보안 측면에서 zkVM은 여전히 취약점 이 많은 매우 복잡한 소프트웨어 프로젝트입니다. 성능 측면에서 프로그램이 올바르게 실행되는지 확인하는 데는 기본적으로 실행하는 것보다 수십만 배나 더 느릴 수 있으므로 현재로선 대부분의 애플리케이션을 현실 세계에 배포하는 것이 불가능합니다.
이러한 실질적인 과제에도 불구하고 블록체인 산업의 대부분 회사는 zkVM을 즉시 배포할 수 있는 것으로 묘사합니다. 실제로 일부 프로젝트는 이미 체인상 활동 증명을 생성하기 위해 상당한 컴퓨팅 비용을 지불했습니다. 하지만 zkVM은 아직 불완전하기 때문에, 이는 실제로는 권한으로 보호되거나, 더 나쁜 경우, 공격에 취약한 시스템이 SNARK로 보호되고 있다고 가장하는 값비싼 방법일 뿐입니다.
안전하고 성능이 뛰어난 zkVM을 갖추기까지는 아직 몇 년이 걸릴 것입니다. 이 게시물에서는 zkVM 진행 상황을 추적하기 위한 일련의 구체적이고 단계적인 목표를 제안합니다. 이러한 목표는 과대광고를 뚫고 커뮤니티가 실제 진행 상황에 집중할 수 있도록 돕습니다.
보안 단계
SNARK 기반 zkVM은 일반적으로 두 가지 주요 구성 요소로 구성됩니다.
다항식에 대한 증명 대화형 오라클(PIOP): 다항식(또는 다항식에서 파생된 제약 조건)에 대한 진술을 증명하기 위한 대화형 증명 프레임워크입니다.
다항식 약속 체계(PCS): 증명자가 다항식의 평가에 대해 거짓말을 할 수 없다는 것을 보장합니다.
zkVM은 기본적으로 유효한 실행 추적을 제약 조건 시스템으로 인코딩합니다. 즉, 가상 머신에서 레지스터와 메모리를 올바르게 사용하도록 강제한다는 의미입니다. 그런 다음 SNARK를 적용하여 이러한 제약 조건이 충족되었는지 증명합니다.
zkVM과 같은 복잡한 시스템이 버그가 없음을 보장하는 유일한 방법은 형식적 검증을 통해서입니다. 보안 단계에 대한 세부 내용은 다음과 같습니다. 1단계에서는 올바른 프로토콜에 초점을 맞추고, 2단계와 3단계에서는 올바른 구현에 초점을 맞춥니다.
보안 단계 1: 올바른 프로토콜
PIOP 신뢰성에 대한 공식 검증 증명;
PCS는 특정 암호화 가정이나 이상적 모델에 따라 구속력 있는 형식적 검증 증명을 갖추고 있습니다.
Fiat-Shamir를 사용하면 PIOP와 PCS를 결합하여 얻은 간결한 주장은 랜덤 오라클 모델에서 안전한 것으로 형식적으로 검증됩니다(필요에 따라 다른 암호화 가정이 추가됨).
PIOP가 적용한 제약 시스템은 VM 의미론의 형식적 검증 증명과 동일하다.
이러한 모든 부분은 VM 바이트코드에서 지정한 모든 프로그램을 실행하는 데 사용할 수 있는 단일의 공식적으로 검증된 보안 SNARK 증명으로 완전히 결합됩니다. 프로토콜이 제로 지식(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년 이내에 3단계에 도달할 zkVM은 없을 것으로 예상합니다. 아마도 그 이상 걸릴 것입니다.
주요 참고 사항: Fiat-Shamir 보안 및 검증된 바이트코드
가장 큰 문제는 피아트-샤미르 변환의 안전성을 둘러싼 해결되지 않은 연구 문제가 있다는 것입니다. 세 단계 모두 Fiat-Shamir와 무작위 오라클을 완벽한 보안의 일부로 간주하지만 실제로는 패러다임 전체에 취약점이 있을 수 있습니다 . 이는 이상화된 무작위 오라클과 실제로 사용되는 해시 함수 사이의 불일치로 인해 발생합니다. 최악의 경우, 2단계에 도달한 시스템은 나중에 피아트-샤미르 문제로 인해 완전히 안전하지 않은 것으로 밝혀질 수 있습니다. 이로 인해 심각한 우려가 제기되었고 연구가 계속 진행되고 있습니다. 이런 유형의 취약점을 더 잘 방지하기 위해 변환 자체를 수정 해야 할 수도 있습니다.
재귀가 없는 시스템은 이론적으로 더 견고합니다. 알려진 일부 공격에는 재귀적 증명에 사용된 것과 유사한 회로가 포함되기 때문입니다.
또한 바이트코드에 명시된 대로 컴퓨터 프로그램이 올바르게 실행되었다는 것을 증명하더라도, 바이트코드 자체에 결함이 있는 경우 그 가치가 제한적이라는 점도 주목할 가치가 있습니다. 따라서 zkVM의 유용성은 공식적으로 검증된 바이트코드를 생성하는 방법에 크게 좌우되는데, 이는 이 논문의 범위를 넘어서는 큰 과제입니다.
양자 이후 시대의 보안에 관하여
양자 컴퓨터는 적어도 앞으로 5년( 아마도 그 이상 ) 동안은 심각한 위협이 되지 않을 것이지만, 그 취약점은 존재적 위험입니다. 따라서 이제는 이 글에서 다루는 보안 및 성능 단계를 충족하는 데 주로 초점을 맞춰야 합니다. 비양자 보안 SNARK를 사용하여 이러한 보안 요구 사항을 더욱 신속하게 충족할 수 있다면, 양자 이후 SNARK가 따라잡을 때까지 이를 수행해야 하며, 사람들이 다른 옵션을 고려하기 전에 암호학적으로 관련 있는 양자 컴퓨터에 대해 심각하게 우려하게 되어야 합니다.
zkVM의 현재 성능
현재 zkVM 증명자가 부담하는 오버헤드 요소는 네이티브 실행 비용의 약 100만 배에 달합니다. 프로그램을 실행하는 데 X 사이클이 걸린다면, 정확한 실행을 증명하는 데 드는 비용은 약 X배 100만 CPU 사이클입니다. 이런 일은 1년 전에도 있었고 , 지금도 여전히 그렇습니다.
대중적인 이야기에서는 이러한 비용을 허용 가능한 것처럼 들리게 표현하는 경우가 많습니다. 예를 들어:
모든 Ethereum 메인넷에 대한 증명을 생성하는 데 드는 비용은 연간 100만 달러 미만입니다.
우리는 수십 개의 GPU 클러스터를 사용하여 거의 실시간으로 Ethereum 블록 증명을 생성할 수 있습니다.
저희의 최신 zkVM은 이전 제품보다 1,000배 더 빠릅니다.
기술적으로 보면 이러한 주장은 정확하지만, 적절한 맥락이 없다면 오해의 소지가 있습니다. 예를 들어:
기존의 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.
최대 검증 시간: 16ms.
이러한 제한은 더 높은 검증 비용이 발생할 수 있는 새로운 빠른 증명 기술을 수용하기 위해 의도적으로 크게 설정됩니다. 동시에 그들은 너무 비용이 많이 들기 때문에 소수의 프로젝트만이 블록체인에 포함시키려는 증명은 제외합니다.
스피드 스테이지 1
단일 스레드 증명은 사전 컴파일에 의존하지 않고도 다양한 애플리케이션(이더리움 블록 증명에만 국한되지 않음)에서 측정했을 때 기본 실행보다 최대 10만 배 느려야 합니다.
이를 좀 더 이해하기 쉽게 설명하자면, 최신 노트북에서 초당 약 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년 안에 스피드 2단계에 도달할 수 있을 것이라고 생각하지만, 아직 나오지 않은 새로운 아이디어 없이는 거기까지 도달할 수 있을지는 불분명합니다. 나머지 단계(스피드 단계 3과 메모리 단계 2)를 달성하는 데는 몇 년이 걸릴 것으로 예상합니다.
요약하다
이 게시물에서는 zkVM의 보안 및 성능 단계를 별도로 식별했지만 zkVM의 이러한 측면은 완전히 독립적이지 않습니다. zkVM에서 더 많은 취약점이 발견됨에 따라, 일부는 성능이 크게 저하되면서만 수정될 것으로 예상됩니다. zkVM이 안전 단계 2에 도달할 때까지 성능을 중단해야 합니다.
zkVM은 제로 지식 증명을 진정으로 보편화할 수 있는 잠재력을 가지고 있지만 아직 초기 단계에 있으며 보안 문제와 상당한 성능 오버헤드가 문제입니다. 과장된 광고와 마케팅 선전으로 인해 실제 진행 상황을 평가하기 어렵습니다. 명확한 안전 및 성과 이정표를 제시함으로써 방해 요소를 제거하기 위한 로드맵을 제공하고자 합니다. 우리는 목표에 도달할 것입니다. 그러나 시간과 지속적인 노력이 필요할 것입니다.
