SNARK(Succinct Non-interactive Arguments of Knowledge)는 블록체인 확장성(예: L2 롤업) 및 개인 정보 보호에 대한 응용 프로그램을 찾는 중요한 암호화 기본 요소입니다. SNARK를 사용하면 누군가가 신뢰할 수 없는 검증자에게 증명할 수 있습니다. V (예: 이더리움 블록체인) 일부 데이터(예: 유효한 트랜잭션 배치)를 알고 있습니다. 이것을 증명하는 순진한 방법은 데이터를 다음으로 보내는 것입니다. V, 누가 그 유효성을 직접 확인할 수 있습니다. SNARK는 동일한 것을 달성하지만 더 나은 비용으로 V. 특히, SNARK 증명은 데이터 자체를 구성하는 순진한 증명보다 짧아야 합니다. (자세한 내용은 제 교과서 초안, 증명, 논증, 영지식. SNARK에 대한 소개는 Sarah Meicklejohn의 프레젠테이션 a16z 암호화에서 여름 연구 시리즈.)
SNARK에 대한 검증 비용은 다양할 수 있지만 잘 이해되고 종종 꽤 좋습니다. 예를 들어, 플롱케이 에 대한 증거 비용 290,000 가스 이더리움에서 검증하기 위해 StarkWare의 증명 비용은 약 5백만 가스입니다. SNARK는 블록체인 외부에서도 다양한 설정에 잠재적으로 적용할 수 있습니다. 예를 들어 빠르고 신뢰할 수 없는 서버 과 하드웨어.
그러나 SNARK 검증은 일반적으로 저렴하기 때문에 적용 가능성의 주요 결정 요인은 SNARK 검증자의 비용입니다. P. 이 게시물에서는 SNARK를 사용하는 것이 합리적인 시점을 결정하기 위해 이러한 비용을 추정하는 방법과 향후 SNARK가 개선될 수 있는 방법을 설명합니다. 이것은 빠르게 움직이는 공간이며 이 게시물에서 논의된 여러 프로젝트가 성능을 적극적으로 개선하고 있다는 점은 주목할 가치가 있습니다.
그러나 먼저: SNARK가 배포되는 방법
SNARK 배포에서 개발자는 일반적으로 컴퓨터 프로그램을 작성합니다. ψ 데이터를 입력으로 취하는 w 증명자가 알고 있다고 주장하는 (w 용 스탠드 목격자)를 확인하고 w 유효합니다. 예를 들어, 롤업에서 프로그램은 모든 트랜잭션이 w 디지털 서명을 하고 계정 잔액이 XNUMX 이하로 떨어지지 않도록 하십시오. 프로그램 ψ 다음을 통해 공급됩니다. 스나크 프론트엔드 SNARK 기술 적용에 더 적합한 형식으로 컴파일합니다. 이 SNARK 친화적 형식을 중간 표현 (가다).
일반적으로 IR은 다음과 같은 일종의 회로 만족도 인스턴스입니다. ψ. 이것은 회로가 C 데이터를 입력으로 사용 w, 그리고 일반적으로 "비결정적 조언"이라고 하는 몇 가지 추가 입력이 실행됩니다. ψ on w. 조언 입력은 다음을 돕기 위해 사용됩니다. C 운영 ψ, 유지하면서 C 작은. 예를 들어 매번 ψ 두 숫자를 나눕니다 x 과 y, 몫 q 그리고 나머지 r 에 대한 조언으로 제공될 수 있습니다. C및 C 간단히 확인할 수 있습니다 x = qy + r. 이 수표는 만드는 것보다 저렴합니다. C 나눗셈 알고리즘을 실행하여 계산 q 과 r 기스로부터.
마지막으로 회로 만족을 위한 SNARK가 적용됩니다. C. 이것은 스나크 백엔드. 다음과 같이 고도로 구조화된 소수의 문제에 대해 행렬 곱셈, 회선및 여러 그래프 문제, 이 프론트엔드/백엔드 패러다임을 피함으로써 훨씬 더 빠른 증명을 달성하는 알려진 SNARK가 존재합니다. 그러나 이 게시물의 초점은 범용 SNARK에 있습니다.
앞으로 살펴보겠지만 SNARK 백엔드의 입증 비용은 다음과 같이 증가합니다. C'에스 크기. 유지 C 회로는 계산을 표현하는 데 있어 극히 제한된 형식이기 때문에 작은 것은 어려울 수 있습니다. 그들은 구성 게이트, 에 의해 연결 전선. 각 게이트 g 일부 값이 제공되고 적용됩니다. 대단히 해당 값에 대한 간단한 기능입니다. 결과는 다음에서 나오는 와이어를 통해 "다운스트림" 게이트로 공급됩니다. g.
SNARK 확장성: 실제로 시간이 얼마나 걸리나요?
핵심 질문은 SNARK Prover가 단순히 재실행하는 것에 비해 얼마나 더 많은 시간이 소요되는지입니다 ψ 데이터에? 정답은 증명자 오버 헤드 SNARK의 상대적인 직접 목격자 확인. 후자의 표현은 다음과 같은 순진한 증명에서 P 전송 w 에 V, V 체크 무늬 w실행하여 의 유효성 ψ 그것에.
Prover 오버헤드를 "프론트엔드 오버헤드"와 "백엔드 오버헤드"로 나누는 것이 도움이 됩니다. 회로를 평가하면 C 게이트 바이 게이트는 F 실행보다 몇 배 더 비쌉니다. ψ, 프론트엔드 오버헤드는 F. 백엔드 증명자를 적용하는 경우 C is B 평가보다 몇 배 더 비쌉니다. C 그러면 백엔드 오버헤드가 B. 총 증명자 오버헤드는 생성물, F·B. 이 승산 오버헤드는 다음과 같은 경우에도 상당할 수 있습니다. F 과 B 개별적으로 겸손합니다.
실제로, F 과 B 둘 다 대략 1000 이상일 수 있습니다. 이것은 직접적인 증인 확인과 관련된 총 증명자 오버헤드가 1만에서 10만 또는 그 이상이 될 수 있음을 의미합니다. 랩톱에서 단 XNUMX초 동안 실행되는 프로그램은 수십 또는 수백 일의 컴퓨팅 시간(단일 스레드)이 필요한 SNARK 증명자로 쉽게 이어질 수 있습니다. 다행히 이 작업은 일반적으로 SNARK에 따라 다양한 범위로 병렬화할 수 있습니다.
요약하자면, 오늘날 애플리케이션에서 SNARK를 사용하려면 다음 세 가지 중 하나가 충족되어야 합니다.
- 직접 목격자 확인은 랩톱에서 XNUMX초도 채 걸리지 않습니다.
- 직접적인 증인 확인은 특히 회로에서 표현하기에 적합하므로 프론트엔드 오버헤드가 적습니다.
- SNARK Prover가 완료될 때까지 며칠을 기다리거나 거대한 병렬 컴퓨팅 리소스에 대한 비용을 지불할 용의가 있습니다.
T그는 이 게시물의 나머지 부분에서 프론트엔드 및 백엔드 오버헤드가 어디에서 발생하는지, 그리고 다양한 SNARK에 대해 이를 어떻게 추정하는지 설명합니다. 그런 다음 개선 가능성을 살펴보겠습니다.
프론트엔드와 백엔드 분리
백엔드에서 프론트엔드를 완전히 분리하는 것은 다른 백엔드가 다양한 종류의 회로를 지원하기 때문에 어려울 수 있습니다. 따라서 프론트엔드는 인터페이스할 백엔드에 따라 다를 수 있습니다.
SNARK 백엔드는 일반적으로 소위 산술 회로를 지원합니다. 즉, 회로에 대한 입력은 일부 유한 필드의 요소이고 회로의 게이트는 두 필드 요소의 덧셈 및 곱셈을 수행합니다. 이러한 회로는 본질적으로 대수적인 직선 컴퓨터 프로그램(분기, 조건문 등 없음)에 대략적으로 대응합니다. 즉, 원시 데이터 유형은 필드 요소입니다.
대부분의 백엔드는 실제로 R1CS(Rank-1 Constraint Satisfaction) 인스턴스라고 하는 산술 회로의 일반화를 지원합니다. 눈에 띄는 예외를 제외하고 그로스16 및 그 전임자, 이러한 SNARK는 다른 IR도 지원하도록 만들 수 있습니다. 예를 들어 StarkWare는 AIR(Algebraic Intermediate Representation)이라는 개념을 사용합니다. PlonKish 산술 PlonK 및 기타 백엔드에서 지원할 수 있습니다. 보다 일반적인 IR을 지원하는 일부 백엔드의 기능은 해당 IR을 생성하는 프런트엔드의 오버헤드를 줄일 수 있습니다.
백엔드는 기본적으로 지원하는 유한 필드 측면에서도 다릅니다. 이에 대해서는 다음 섹션에서 더 논의하겠습니다.
프론트엔드에 대한 다양한 접근
일부(매우 특별한) 컴퓨터 프로그램은 자연적으로 산술 회로에 해당합니다. 한 가지 예는 일부 필드에 대해 행렬의 순진한 곱셈을 수행하는 컴퓨터 프로그램입니다. 그러나 대부분의 컴퓨터 프로그램은 직선도 대수도 아닙니다. 그들은 종종 조건문, 유한 필드 산술에 자연적으로 대응하지 않는 정수 나눗셈 또는 부동 소수점 산술과 같은 연산을 포함합니다. 이러한 경우 프런트엔드 오버헤드가 상당합니다.
널리 사용되는 프론트엔드 접근 방식은 기본적으로 가상 머신(VM)이라고도 하는 간단한 CPU를 단계별로 실행하는 회로를 생성하는 것입니다. 프론트엔드 설계자는 실제 컴퓨터 프로세서에 대한 조립 지침과 유사한 "기본 작업" 세트를 지정합니다. 프론트엔드를 사용하려는 개발자는 어셈블리 언어로 직접 "증인 확인 프로그램"을 작성하거나 Solidity와 같은 고급 언어로 프로그램을 자동으로 컴파일하여 어셈블리 코드로 만들 것입니다.
예를 들어 StarkWare의 카이로 어셈블리 명령어가 유한 필드, 함수 호출, 불변(즉, 한 번 쓰기) 메모리에 대한 읽기 및 쓰기에 대한 대략적인 덧셈 및 곱셈을 허용하는 매우 제한된 어셈블리 언어입니다. Cairo VM은 von Neumann 아키텍처로, 프론트엔드에서 생성된 회로는 기본적으로 Cairo 프로그램을 공개 입력으로 사용하고 증인에서 프로그램을 "실행"합니다. Cairo 언어는 Turing Complete입니다. 제한된 명령어 세트에도 불구하고 비용이 많이 들지만 더 많은 표준 아키텍처를 시뮬레이션할 수 있습니다. Cairo 프론트엔드는 Cairo 프로그램을 실행합니다. T "학위"라고 불리는 것에 대한 원시적 지시2 에어 T 행 및 정보 50 열." 뭐 정확히 이것은 의미 이 게시물에서는 중요하지 않지만 SNARK 증명자에 관한 한 이것은 각 회로에 대해 50~100개의 게이트가 있는 회로에 해당합니다. T 카이로 CPU의 단계.
RISC 제로 카이로와 유사한 접근 방식을 취하지만 가상 머신이 RISC-V 아키텍처, 인기가 높아지고 있는 풍부한 소프트웨어 에코시스템을 갖춘 오픈 소스 아키텍처입니다. 매우 간단한 명령어 세트로서 이를 지원하는 효율적인 SNARK 프런트엔드를 설계하는 것은 상대적으로 다루기 쉬울 수 있습니다(적어도 x86 또는 ARM과 같은 복잡한 아키텍처와 관련하여). XNUMX월 현재 RISC Zero 프로그램을 돌리고 있습니다 실행 T 기본 RISC-V 명령어를 5차 AIR로 3T 행 및 160 열. 이것은 적어도 500 RISC-V CPU의 단계당 게이트. 가까운 시일 내에 추가 개선이 예상됩니다.
다양한 zkEVM 프로젝트(예: zkSync 2.0, Scroll, Polygon의 zkEVM)는 가상 머신을 이더리움 가상 머신으로 간주합니다. 모든 EVM 명령어를 동등한 "가제트"(즉, 명령어를 구현하는 최적화된 회로)로 바꾸는 프로세스는 더 단순한 Cairo 및 RISC-V 아키텍처보다 훨씬 더 복잡합니다. 이것과 다른 이유로, 일부 zkEVM 프로젝트 EVM 명령어 세트를 직접 구현하는 것이 아니라 높은 수준의 Solidity 프로그램을 회로로 변환하기 전에 다른 어셈블리 언어로 컴파일합니다. 이 프로젝트의 성과 결과가 보류 중입니다.
RISC-V 및 Cairo와 같은 "CPU 에뮬레이터" 프로젝트는 관련 어셈블리 언어의 모든 프로그램을 처리할 수 있는 단일 회로를 생성합니다. 대안적인 접근 방식은 "ASIC과 유사"하여 다른 프로그램에 대해 다른 회로를 생성합니다. 이 ASIC과 같은 접근 방식은 일부 프로그램에 대해 더 작은 회로를 생성할 수 있습니다. 특히 프로그램이 각 시간 단계에서 실행하는 어셈블리 명령이 프로그램의 입력에 의존하지 않을 때 그렇습니다. 예를 들어, 순진한 행렬 곱셈과 같은 직선 프로그램에 대한 프론트엔드 오버헤드를 완전히 피할 수 있습니다. 그러나 ASIC 접근 방식도 매우 제한적인 것으로 보입니다. 내가 아는 한, 미리 결정된 반복 범위 없이 루프를 지원하는 데 사용하는 방법은 알려져 있지 않습니다.
프런트엔드 오버헤드의 마지막 구성 요소는 모든 SNARK가 유한 필드에서 작동하는 회로를 사용한다는 사실에서 비롯됩니다. 랩톱의 CPU는 단일 기계 명령으로 두 개의 정수를 곱하거나 더할 수 있습니다. 프론트엔드가 충분히 큰 특성의 필드에 대해 회로를 출력하면 기본적으로 해당 필드 연산을 통해 곱셈 또는 덧셈을 시뮬레이션할 수 있습니다. 그러나 실제 CPU에서 필드 작업을 구현하려면 일반적으로 많은 기계 명령이 필요합니다(일부 최신 프로세서에는 특정 필드에 대한 기본 지원이 있음).
일부 SNARK 백엔드는 다른 것보다 더 유연한 필드 선택을 가능하게 합니다. 예를 들어 백엔드가 암호화 그룹을 사용하는 경우 G, 회로의 필드는 요소의 수와 일치해야 합니다. G, 제한적일 수 있습니다. 또한 모든 필드가 실용적인 FFT 알고리즘을 지원하는 것은 아닙니다.
구현된 SNARK는 하나만 있으며, 분류, 기본적으로 임의의(충분히 큰) 필드에 대한 계산을 지원합니다. 그것과 함께 후손, 다른 SNARK가 지원하는 분야에서도 가장 빠르게 알려진 구체적인 증명자 성능을 가지고 있지만 현재 많은 블록체인 응용 프로그램에 대해 증명이 너무 큽니다. 최근의 일 증명 크기를 개선하려고 하지만 증명자는 점근적으로 느리고 보인다 장벽 실용성에.
일부 프로젝트는 특히 빠른 산술을 사용하는 필드에서 작업하기로 선택했습니다. 예를 들어, 플롱키2 다른 사람들은 특성 2의 필드를 사용합니다.64 - 232 + 1 이 필드의 산술은 덜 구조화된 필드보다 몇 배 더 빠르게 구현될 수 있기 때문입니다. 그러나 이러한 작은 특성을 사용하면 필드 연산을 통해 정수 산술을 효율적으로 표현하는 데 문제가 발생할 수 있습니다(예: 두 개의 32비트 부호 없는 정수를 곱하면 필드 특성보다 큰 결과가 생성될 수 있음).
그러나 무엇이든 간에 오늘날 인기 있는 모든 SNARK가 128비트 보안을 달성하려면(검증 비용의 상당한 증가 없이) 2보다 큰 크기의 필드에서 작업해야 합니다.128. 내가 말할 수 있는 한, 이것은 각 필드 연산이 적어도 약 64개의 XNUMX비트 기계 곱셈과 훨씬 더 많은 덧셈 및 비트 연산을 필요로 한다는 것을 의미합니다. 따라서 유한 필드에서 작동하는 회로가 필요하기 때문에 최소한 XNUMX배 이상의 프런트엔드 오버헤드를 고려해야 합니다.
요약하면 가상 머신 추상화를 사용하는 기존 프런트엔드는 가상 머신의 단계당 100~1000x 게이트가 있는 회로를 생성하며 더 복잡한 가상 머신의 경우 더 많을 수 있습니다. 게다가 유한 필드 산술은 최신 프로세서의 유사한 명령어보다 최소 10배 느립니다(프로세서에 특정 필드에 대한 내장 지원이 있는 경우 예외 가능). "ASIC 프론트엔드 접근 방식"은 이러한 오버헤드 중 일부를 줄일 수 있지만 현재 지원할 수 있는 프로그램 종류는 제한적입니다.
백엔드 병목 현상은 무엇입니까?
회로 만족을 위한 SNARK는 일반적으로 "다항식 IOP"라고 하는 암호화 프로토콜을 사용합니다.다항식 확약 방식.” 대부분의 경우 증명자의 구체적인 병목 현상은 다항식 확약 방식입니다. 특히, 이러한 SNARK는 증명자가 (적어도) |C|, 회로의 게이트 수 C.
차례로, 다항식 확약 방식 내의 구체적인 병목 현상은 사용된 방식과 회로 크기에 따라 달라집니다. 그러나 항상 다음 세 가지 작업 중 하나가 됩니다. FFT 계산, 암호화 그룹의 지수, 또는 머클 해싱. Merkle-hashing은 일반적으로 회로가 작은 경우에만 병목 현상이 발생하므로 더 이상 논의하지 않겠습니다.
이산 로그 기반 다항식 약정
암호화 그룹의 이산 로그 문제의 경도에 기반한 다항식 약정에서 G (KZG, 방탄, 평저 어선및 Hyrax 커밋), 증명자는 다음을 계산해야 합니다. Pedersen 벡터 약속 다항식의 계수. 여기에는 다항식의 차수와 동일한 크기의 다중 지수가 포함됩니다. SNARK에서 이 정도는 일반적으로 크기 |C| 회로 C.
순진하게, 크기의 다중 지수화 |C| 약 1.5 필요·|C|·기록 |G| ≈ 400·|C| 그룹 작업, 여기서 |G| 그룹의 요소 수를 나타냅니다. G. 그러나 Pippenger의 알고리즘이라고 하는 접근 방식이 있습니다. 이를 통해 대략 log |C|. 큰 회로의 경우(예: |C| ≥ 225), 이 로그 |C| factor는 구체적으로 25 또는 그 이상이 될 수 있습니다.·|C| 그룹 운영. 각 그룹 작업은 유한 필드 작업보다 약 10배 느린 경향이 있습니다. 이러한 다항식 약정을 사용하는 SNARK는 P 약 100·|C| 현장 작업.
불행히도 기존 SNARK에는 위의 100배 요소 외에 추가 오버헤드가 있습니다. 예를 들어:
- 스파르타의Hyrax 다항식 확약을 사용하는 의 증명자는 다음을 수행해야 합니다. |C|½ 각각의 크기에 대한 많은 다중 지수 |C|½, Pippenger 알고리즘의 속도 향상을 약 XNUMX배 정도 약화시킵니다.
- In 그로스16, P 페어링 친화적 그룹에 대해 작업해야 합니다. 이 그룹의 작업은 일반적으로 페어링 친화적이지 않은 그룹보다 2배 이상 느립니다. P 또한 3이 아닌 1개의 다중 지수를 수행해야 합니다. 결합하면 6에 비해 최소한 추가 요소 100이 느려집니다.·|C| 위의 견적.
- 돛새치과의 큰 물고기 과 플롱케이 또한 쌍이 필요하고 증명자는 3개 이상의 다항식에 커밋해야 합니다.
- 사용하는 모든 SNARK의 경우 방탄 (예 : Halo2, 대략 PlonK이지만 KZG 다항식 약정이 아닌 Bulletproofs를 사용하는 경우), 증명자는 약정 계획의 "개방" 단계에서 대수적으로 많은 다중 지수를 계산해야 하며 이는 Pippenger 속도 향상을 크게 지웁니다.
요약하면 Pedersen 벡터 커밋을 사용하는 알려진 SNARK는 백엔드 오버헤드가 최소 200배에서 최대 1000배 이상인 것으로 보입니다.
기타 다항식 약정
다른 다항식 약정을 사용하는 SNARK의 경우(예: 무료 과 리게로 커밋), 병목 현상은 증명자가 대규모 FFT를 수행해야 한다는 것입니다. 예를 들어 Cairo에서 생산한 2급 AIR(51개의 열과 T 행, Cairo CPU의 단계당 하나씩), StarkWare의 배포된 증명자는 열당 최소 2개의 FFT를 수행합니다. 16 ·T 과 32 ·T. 상수 16 과 32 StarkWare에서 설정한 FRI의 내부 매개변수에 따라 달라지며 줄일 수 있지만 검증 비용이 증가합니다.
낙관적으로, 길이 32의 FFT·T 약 64 소요·T·로그(32T) 필드 곱셈. 이는 상대적으로 작은 값의 경우에도 T (예 : T ≥ 220), 열당 필드 연산 수는 64개 이상입니다.·25·T= 1600·T. 따라서 백엔드 오버헤드는 적어도 수천 개로 나타납니다. 또한 대규모 FFT는 필드 작업보다 메모리 대역폭에 의해 병목 현상이 더 많이 발생할 수 있습니다.
일부 상황에서 대규모 FFT를 수행하는 SNARK의 백엔드 오버헤드는 증명 집계라는 기술을 사용하여 완화할 수 있습니다. 롤업의 경우 이는 다음을 의미합니다. P (롤업 서비스)는 대규모 트랜잭션 배치를 예를 들어 10개의 더 작은 배치로 나눕니다. 각 작은 배치에 대해 i, P SNARK 증거 생성 πi 배치의 유효성. 하지만 P 가스 비용이 거의 10배 증가하기 때문에 이 증명을 Ethereum에 게시하지 않습니다. 대신 SNARK를 다시 적용하여 이번에는 증명을 생성합니다. π 그것을 확립 P 알고있다 π1 ...,π10. 즉 증인이 P 알고 있다는 주장은 XNUMX개의 증명 π입니다.1,…, 파이10, 직접 증인 확인은 각 증명에 SNARK 검증 절차를 적용합니다. 이 단 하나의 증거 π 이더리움에 게시됩니다.
FRI 및 Ligero-commit과 같은 다항식 커밋에서는 P 시간과 V 비용, 내부 매개변수가 서로를 교환할 수 있는 손잡이 역할을 합니다. 부터 π1 ,…, 파이10 이더리움에 게시되지 않은 경우 노브를 조정할 수 있으므로 이러한 증거가 크기가 크고 생산 속도가 더 빠릅니다. SNARK의 최종 응용 프로그램에서만 집계 π1 ,…, 파이10 하나의 증거로 π, 작은 증거를 보장하기 위해 확약 체계를 구성해야 합니까?
StarkWare는 증명 집계를 배포할 계획입니다. 임박한. 이것은 또한 다음과 같은 프로젝트의 초점입니다. 플롱키2.
SNARK 확장성의 다른 병목 현상은 무엇입니까?
이 게시물은 증명자에 초점을 맞췄습니다. 시간, 그러나 다른 입증 비용도 확장성 병목 현상이 될 수 있습니다. 예를 들어, 많은 SNARK 백엔드의 경우 Prover는 각 게이트에 대해 여러 필드 요소를 저장해야 합니다. C, 이 공간 비용은 엄청날 수 있습니다. 예를 들어, 프로그램 ψ 랩톱에서 XNUMX초 동안 실행하면 최신 프로세서에서 수십억 개의 기본 작업을 수행할 수 있습니다. 우리가 보았듯이 일반적으로 C 그러한 작업당 100개 이상의 게이트가 필요합니다. 이것은 100억 개의 게이트를 의미하며, SNARK에 따라 수십 또는 수백 테라바이트의 공간을 의미할 수 있습니다. P.
또 다른 예: 많은 인기 있는 SNARK(예: 플롱케이, 돛새치과의 큰 물고기, 그로스16) 구조화된 "인증 키"를 생성하려면 복잡한 "신뢰할 수 있는 설정 절차"가 필요합니다. 증명자가 저장해야 합니다. 내가 아는 한, 가장 큰 행사 약 2개의 회로를 지원할 수 있는 증명 키 생성28≈250억 XNUMX천만 게이트. 증명 키는 수십 기가바이트 크기입니다.
증명 집계가 가능한 상황에서 이러한 병목 현상은 상당히 완화될 수 있습니다.
앞을 내다보기: 더 확장 가능한 SNARK에 대한 전망
프론트엔드와 백엔드 오버헤드는 모두 XNUMX배 이상일 수 있습니다. 가까운 장래에 이러한 수치가 크게 낮아질 것으로 예상할 수 있습니까?
나는 우리가 할 것이라고 생각합니다. 첫째, 오늘날 가장 빠른 백엔드(예: 스파르타의 과 분류, 및 결합하는 다른 SNARK 합계 확인 프로토콜 다항식 약정 포함) 큰 증명(일반적으로 회로 크기의 제곱근)이 있으므로 사람들이 실제로 사용하지 않습니다. 나는 small-proof SNARKs를 가진 depth-one 구성을 통해 가까운 장래에 증명 크기와 검증자 시간이 의미있게 줄어들 것으로 기대합니다. 증명 집계와 유사하게 이는 증명자가 먼저 SNARK 증명을 생성한다는 것을 의미합니다. π "빠른 증명자, 큰 증거"SNARK를 사용하지만 전송하지 않습니다. π 에 V. 차라리, P 증거를 생성하기 위해 소형 증거 SNARK를 사용합니다. π' 그것은 알고있다 π, 보내 π' 에 V. 이것은 오늘날 인기 있는 SNARK의 백엔드 오버헤드를 크게 줄일 수 있습니다.
둘째, 하드웨어 가속이 도움이 될 수 있습니다. 매우 대략적인 일반적인 규칙은 GPU는 CPU보다 10배, ASIC은 GPU보다 10배 빨라진다는 것입니다. 그러나 나는 이 면에서 세 가지 우려가 있다. 첫째, 대규모 FFT는 필드 작업보다 메모리 대역폭에 의해 병목 현상이 발생할 수 있으므로 이러한 FFT를 수행하는 SNARK는 특수 하드웨어에서 제한된 속도 향상을 볼 수 있습니다. 둘째, 이 게시물이 다항식 커밋 병목 현상에 초점을 맞추었지만 많은 SNARK는 증명자가 약간 더 저렴한 다른 작업을 수행하도록 요구합니다. 따라서 다항식 커밋 병목 현상(예: 다중 지수의 속도 향상 이산 로그 기반 SNARK에서) 이전 작업보다 훨씬 좋지 않은 새로운 병목 작업을 남길 수 있습니다. (예를 들어, Groth16, Marlin 및 PlonK를 포함한 SNARK에는 다중 지수 외에도 FFT를 수행하는 증명자가 있습니다.) 마지막으로, 가장 효율적인 SNARK로 이어지는 필드와 타원 곡선은 한동안 계속 발전할 수 있으며, 이는 ASIC 기반 증명자 가속에 대한 도전을 생성할 수 있습니다.
프론트엔드 측면에서 Cairo, RISC Zero, zkEVM 등과 같은 프로젝트의 "CPU 에뮬레이터" 접근 방식이 CPU 명령어 세트의 복잡성으로 인해 실제로 (성능 측면에서) 꽤 잘 확장된다는 것을 점점 더 많이 알게 될 것입니다. 실제로 이것은 다양한 zkEVM 프로젝트의 희망 사항입니다. 이는 프런트엔드 오버헤드가 XNUMX배 이상으로 유지되는 동안 프런트엔드가 실제 CPU 아키텍처와 점점 더 일치하는 VM을 지원할 수 있음을 의미할 수 있습니다. 상쇄되는 우려는 점점 더 복잡한 명령을 구현하는 손으로 코딩된 가제트가 급증함에 따라 프런트엔드가 복잡해지고 감사하기 어려워질 수 있다는 것입니다. 공식 검증 방법은 이 문제를 해결하는 데 중요한 역할을 할 것입니다.
마지막으로, 적어도 블록체인 애플리케이션에서 우리는 야생에서 나타나는 대부분의 스마트 계약이 주로 단순하고 SNARK 친화적인 명령을 사용한다는 것을 발견할 수 있습니다. 이것은 Solidity와 같은 고급 프로그래밍 언어와 EVM을 포함한 풍부한 명령어 세트 지원과 함께 제공되는 일반성과 향상된 개발자 경험을 유지하면서 실제로 프런트엔드 오버헤드를 낮출 수 있습니다.
***
저스틴 탈러 is 조지타운 대학교 부교수. Georgetown에 합류하기 전에 그는 뉴욕에 있는 Yahoo Labs에서 연구원으로 XNUMX년을 보냈습니다. 시몬스 컴퓨팅 이론 연구소 UC 버클리에서.
***
감사의 말: 감사합니다. 엘레나 버거 이 게시물의 주제를 제안하고 아라수 아룬, 조셉 보노및 샘 랙스데일 통찰력 있는 의견을 위해. 편집자님께도 특별히 감사드립니다. 팀 설리반.
***
여기에 표현된 견해는 인용된 개별 AH Capital Management, LLC("a16z") 직원의 견해이며 16z 또는 그 계열사의 견해가 아닙니다. 여기에 포함된 특정 정보는 16z가 관리하는 펀드의 포트폴리오 회사를 포함하여 제16자 출처에서 얻은 것입니다. 신뢰할 수 있다고 여겨지는 출처에서 가져왔지만 16z는 그러한 정보를 독립적으로 검증하지 않았으며 정보의 지속적인 정확성이나 주어진 상황에 대한 적절성에 대해 어떠한 진술도 하지 않습니다. 또한 이 콘텐츠에는 타사 광고가 포함될 수 있습니다. XNUMXz는 그러한 광고를 검토하지 않았으며 여기에 포함된 광고 콘텐츠를 보증하지 않습니다.
이 콘텐츠는 정보 제공의 목적으로만 제공되며 법률, 비즈니스, 투자 또는 세금 관련 조언에 의존해서는 안 됩니다. 그러한 문제에 관해서는 자신의 고문과 상의해야 합니다. 증권 또는 디지털 자산에 대한 언급은 설명을 위한 것일 뿐이며 투자 추천이나 투자 자문 서비스 제공을 의미하지 않습니다. 또한, 이 콘텐츠는 투자자 또는 예비 투자자를 대상으로 하거나 사용하도록 의도되지 않았으며, 어떤 상황에서도 a16z가 관리하는 펀드에 투자하기로 결정할 때 의존할 수 없습니다. (16z 펀드에 대한 투자 제안은 사모 투자 각서, 청약 계약서 및 해당 펀드의 기타 관련 문서에 의해서만 이루어지며 전체 내용을 읽어야 합니다.) 언급되거나 언급된 모든 투자 또는 포트폴리오 회사 설명된 내용은 16z가 관리하는 차량에 대한 모든 투자를 대표하는 것은 아니며 투자가 수익성이 있거나 미래에 수행되는 다른 투자가 유사한 특성 또는 결과를 가질 것이라는 보장이 없습니다. Andreessen Horowitz가 관리하는 펀드의 투자 목록(발행자가 16z가 공개적으로 공개하도록 허가하지 않은 투자 및 공개적으로 거래되는 디지털 자산에 대한 미고지 투자 제외)은 https://a16z.com/investments에서 볼 수 있습니다. /.
내부에 제공된 차트와 그래프는 정보 제공의 목적으로만 사용되며 투자 결정을 내릴 때 의존해서는 안 됩니다. 과거의 성과는 미래의 결과를 나타내지 않습니다. 내용은 표시된 날짜 현재만 말합니다. 이 자료에 표현된 모든 예측, 추정, 예측, 목표, 전망 및/또는 의견은 예고 없이 변경될 수 있으며 다른 사람이 표현한 의견과 다르거나 반대될 수 있습니다. 추가 중요 정보는 https://a16z.com/disclosures를 참조하십시오.
