첫 번째 레벨 제목
영지식증명 개발 프레임워크 평가 플랫폼 "판테온"
지난 몇 달 동안 우리는 zk-SNARK 간결한 증명으로 구축된 최첨단 인프라를 개발하는 데 많은 시간과 노력을 투자했습니다. 이 차세대 혁신 플랫폼을 통해 개발자는 블록체인 애플리케이션의 전례 없는 새로운 패러다임을 구축할 수 있습니다.
개발 작업에서 다양한 영지식 증명(ZKP) 개발 프레임워크를 테스트하고 사용했습니다. 이 여정은 보람이 있었지만 특정 사용 사례 및 성능 요구 사항에 가장 적합한 프레임워크를 찾으려고 노력하는 새로운 개발자에게 다양한 ZKP 프레임워크가 종종 도전 과제를 제시한다는 것을 알고 있습니다. 이러한 문제점을 고려할 때 포괄적인 성능 테스트 결과를 제공할 수 있는 커뮤니티 평가 플랫폼이 필요하며, 이는 이러한 새로운 애플리케이션의 개발을 크게 촉진할 것입니다.
이러한 요구를 충족시키기 위해 우리는영지식증명 개발 프레임워크 평가 플랫폼 "판테온"이 공익 커뮤니티 이니셔티브. 이니셔티브의 첫 번째 단계는 커뮤니티가 공유하도록 장려합니다.재현 가능한 성능 테스트 결과. 우리의 궁극적인 목표는 공동으로 만들고 유지하는 것입니다.널리 알려진 테스트 플랫폼,첫 번째 레벨 제목
1단계: SHA-256을 사용한 회로 프레임워크의 성능 테스트
이 기사에서는 재현 가능한 일련의 성능 테스트 결과를 제공하기 위해 일련의 저수준 회로 개발 프레임워크에서 SHA-256을 사용하여 ZKP Pantheon을 구축하는 첫 번째 단계를 수행합니다. 우리는 다른 성능 테스트 세분성 및 기본 요소가 가능할 수 있음을 인정하지만 블록체인 시스템, 디지털 서명, zkDID 등을 포함한 광범위한 ZKP 사용 사례에 적합하기 때문에 SHA-256을 선택했습니다. 또한 자체 시스템에서도 SHA-256을 사용하므로 이는 우리에게도 편리합니다!
보조 제목
증거 시스템
최근 몇 년 동안 우리는 영지식 증명 시스템의 확산을 목격했습니다. 이 분야의 모든 흥미로운 발전을 따라잡는 것은 어려운 일이며 성숙도 및 개발자 채택을 기반으로 테스트를 위해 다음과 같은 증명 시스템을 직접 선택했습니다. 우리의 목표는 다양한 프런트엔드/백엔드 조합의 대표적인 샘플을 제공하는 것입니다.
Circom + snarkjs / rapidsnark: Circcom은 회로를 작성하고 R 1 CS 제약 조건을 생성하는 데 널리 사용되는 DSL이며, snarkjs는 Circcom용 Groth 16 또는 Plonk 증명을 생성할 수 있습니다. Rapidsnark는 또한 Circcom의 증명자이며 Groth 16 증명을 생성하며 ADX 확장을 사용하고 증명 생성을 최대한 병렬화하기 때문에 종종 snarkjs보다 훨씬 빠릅니다.
gnark:gnark는 Groth 16, Plonk 및 기타 여러 고급 기능을 지원하는 Consensys의 포괄적인 Golang 프레임워크입니다.
Arkworks: Arkworks는 zk-SNARK를 위한 포괄적인 Rust 프레임워크입니다.
Halo 2 (KZG): Halo 2는 Zcash와 Plonk를 zk-SNARK로 구현한 것입니다. 그것은 매우 유연한 Plonkish 산술을 갖추고 있으며 사용자 정의 게이트웨이 및 조회 테이블과 같은 많은 유용한 프리미티브를 지원합니다. 우리는 Ethereum Foundation 및 Scroll 지원과 함께 KZG의 Halo 2 포크를 사용합니다.
Plonky 2 : Plonky 2는 Polygon Zero의 PLONK 및 FRI 기술을 기반으로 한 SNARK 구현입니다. Plonky 2는 작은 Goldilocks 필드를 사용하고 효율적인 재귀를 지원합니다. 성능 테스트에서 우리는 100비트의 추측 보안을 목표로 하고 성능 테스트 노력에 대한 최상의 증명 시간을 산출하는 매개변수를 사용합니다. 구체적으로, 우리는 28개의 Merkle 쿼리, 증폭 계수 8, 16비트 작업 증명 챌린지를 사용했습니다. 또한 num_of_wires = 60 및 num_routed_wires = 60으로 설정합니다.
Starky: Starky는 Polygon Zero의 고성능 STARK 프레임워크입니다. 성능 테스트에서 우리는 100비트의 추측 보안을 목표로 하고 최상의 검증 시간을 산출하는 매개변수를 사용합니다. 구체적으로, 우리는 90개의 Merkle 쿼리, 2x 증폭 계수 및 10비트 작업 증명 챌린지를 사용했습니다.
아래 표에는 성능 테스트에 사용된 위의 프레임워크 및 관련 구성이 요약되어 있습니다. 이 목록은 결코 완전하지 않으며 향후 많은 최신 프레임워크/기술(예: Nova, GKR, Hyperplonk)을 조사할 것입니다.
이러한 성능 테스트 결과는 회로 개발 프레임워크 전용입니다. 향후 다양한 zkVM(예: Scroll, Polygon zkEVM, Consensys zkEVM, zkSync, Risc Zero, zkWasm) 및 IR 컴파일러 프레임워크(예: Noir, zkLLVM)의 성능 테스트와 함께 별도의 기사를 게시할 계획입니다.
성과평가 방법론
이러한 다양한 증명 시스템에서 성능 테스트를 수행하기 위해 N바이트 데이터의 SHA-256 해시를 계산합니다. 여기서 N = 64, 128, ..., 64K로 실험합니다(Starky는 예외입니다. SHA-256 고정 64바이트 입력의 계산이지만 총 메시지 블록 수는 동일하게 유지합니다. 허용이 저장소성능 코드 및 SHA-256 회로 구성은 에 있습니다.
또한 다음 성능 메트릭을 사용하여 각 시스템에서 성능 테스트를 수행했습니다.
증명 생성 시간(증인 생성 시간 포함)
증명 생성 중 메모리 사용량 급증
증명 생성 중 CPU 사용량의 평균 백분율입니다. (이 메트릭은 증명 생성 프로세스의 병렬화 정도를 반영합니다.)
보조 제목
기계
서로 다른 두 대의 시스템에서 성능 테스트를 실행했습니다.
Linux 서버: 2.3GHz @ 20코어, 384GB RAM
Macbook M 1 Pro: 10코어 @ 3.2Ghz, 16GB RAM
Linux 서버는 다수의 CPU 코어와 충분한 메모리가 있는 시나리오를 시뮬레이션하는 데 사용됩니다. 주로 연구개발용으로 사용되는 맥북 M 1 프로는 CPU는 더 강력하지만 코어 수는 적다.
보조 제목
텍스트
제약 수량
자세한 성능 테스트 결과로 이동하기 전에 먼저 각 증명 시스템의 제약 조건 수를 살펴봄으로써 SHA-256의 복잡성을 이해하는 것이 유용합니다. 서로 다른 산술 방식의 제약 조건 수를 직접 비교할 수 없다는 점에 유의해야 합니다.
아래 결과는 64KB의 사전 이미지 크기에 해당합니다. 결과는 다른 사전 이미지 크기에 따라 다를 수 있지만 대략 선형으로 확장됩니다.
Circcom, gnark 및 Arkworks는 모두 동일한 R 1 CS 알고리즘을 사용하며 64KB SHA-256을 계산하기 위한 R 1 CS 제약 조건의 수는 대략 30M에서 45M 사이입니다. Circom, gnark 및 Arkworks 간의 차이점은 구성 차이 때문일 수 있습니다.
Halo 2와 Plonky 2는 모두 Plonkish 산술을 사용하며 행 수는 2^22에서 2^23까지입니다. Halo 2의 SHA-256 구현은 조회 테이블을 사용하기 때문에 Plonky 2보다 훨씬 더 효율적입니다.
텍스트
증명 생성 시간
[그림 1] Linux 서버를 사용하여 다양한 Raw 이미지 크기에서 SHA-256의 각 프레임의 증명 생성 시간을 테스트했습니다. 다음과 같은 결과를 얻을 수 있습니다.
SHA-256의 경우 Groth 16 프레임워크(rapidsnark, gnark 및 Arkworks)가 Plonk 프레임워크(Halo 2 및 Plonky 2)보다 빠르게 증명을 생성했습니다. 이는 SHA-256이 대부분 와이어 값이 0 또는 1인 비트 연산으로 구성되기 때문입니다. Groth 16의 경우 이것은 타원 곡선 스칼라 곱셈에서 타원 곡선 점 추가까지 대부분의 계산을 줄입니다. 그러나 와이어 값은 Plonk의 계산에서 직접 사용되지 않으므로 SHA-256의 특수 와이어 구조는 Plonk 프레임워크에서 필요한 계산량을 줄이지 않습니다.
모든 Groth 16 프레임워크 중에서 gnark 및 rapidsnark는 Arkworks 및 snarkjs보다 5~10배 더 빠릅니다. 이는 여러 코어를 활용하여 증명 생성을 병렬화하는 놀라운 능력 때문입니다. Gnark는 rapidsnark보다 25% 더 빠릅니다.
Plonk 프레임워크의 경우 Plonky 2의 SHA-256은 더 큰 사전 이미지 크기 >= 4KB를 사용할 때 Halo 2보다 50% 느립니다. 이는 Halo 2 구현이 주로 조회 테이블을 사용하여 비트 연산 속도를 높여 Plonky 2보다 2배 적은 행을 생성하기 때문입니다. 그러나 Plonky 2와 Halo 2를 동일한 수의 행과 비교하면(예: Halo 2에서 2KB를 초과하는 SHA-256 대 Plonky 2에서 4KB를 초과하는 SHA-256) Plonky 2가 Halo보다 50% 더 빠릅니다. 2. 조회 테이블을 사용하여 Plonky 2에서 SHA-256을 구현하는 경우 Plonky 2의 증명 크기가 더 크더라도 Plonky 2가 Halo 2보다 빠를 것으로 예상해야 합니다.
반면에 입력 프리이미지 크기가 작은 경우(<= 512바이트) Halo 2는 제약 조건의 대부분을 차지하는 조회 테이블의 고정 설정 비용으로 인해 Plonky 2(및 기타 프레임워크)보다 느립니다. 그러나 Halo 2의 성능은 프리이미지 크기가 증가함에 따라 더욱 경쟁력이 있으며 입증된 생성 시간은 그림과 같이 거의 선형으로 확장되는 최대 2KB의 프리이미지 크기에 대해 일정하게 유지됩니다.
예상대로 Starky의 증명 생성 시간은 SNARK 프레임워크보다 훨씬 짧지만(5x-50x) 더 큰 증명 크기를 희생해야 합니다.
또한 회로 크기가 프리이미지 크기에 따라 선형적으로 확장되더라도 O(nlogn) FFT로 인해 SNARK에 대한 증명 생성이 초선형적으로 증가합니다(이 현상은 로그 스케일로 인해 그래프에 표시되지 않음).
또한 [그림 2]와 같이 Macbook M 1 Pro에서 증명 생성 시간 성능 테스트를 수행했습니다. 그러나 arm 64 아키텍처에 대한 지원 부족으로 인해 rapidsnark가 이 벤치마크에 포함되지 않았다는 점에 유의해야 합니다. arm 64에서 snarkjs를 사용하려면 웹어셈블리를 사용하여 감시를 생성해야 하는데 이는 Linux 서버에서 사용되는 C++ 감시 생성보다 느립니다.
Macbook M 1 Pro에서 성능 테스트를 실행할 때 몇 가지 추가 관찰:
Starky를 제외하고 모든 SNARK 프레임워크는 메모리 부족(OOM) 오류가 발생하거나 사전 이미지 크기가 커짐에 따라 스왑 메모리(증명 시간이 느려짐)를 사용합니다. 특히 Groth 16 프레임워크(snarkjs, gnark, Arkworks)는 사전 이미지 크기 >= 8KB에서 스왑 메모리를 사용하기 시작하는 반면, gnark는 사전 이미지 크기 >= 64KB에서 메모리가 부족합니다. Halo 2는 사전 이미지 크기가 >= 32KB일 때 메모리 제한에 도달했습니다. Plonky 2는 사전 이미지 크기가 >= 8KB일 때 스왑 메모리를 사용하기 시작합니다.
보조 제목
최대 메모리 사용량
[그림 3]과 [그림 4]는 각각 Linux Server와 Macbook M 1 Pro에서 증명 생성 시 최대 메모리 사용량을 보여줍니다. 이러한 성능 테스트 결과에서 다음과 같은 관찰 결과를 도출할 수 있습니다.
모든 SNARK 프레임워크 중에서 rapidsnark는 메모리 효율성이 가장 높습니다. 또한 Halo 2는 룩업 테이블의 고정 설정 비용으로 인해 사전 이미지 크기가 더 작을 때 더 많은 메모리를 사용하지만 사전 이미지 크기가 더 클 때 전체적으로 더 적은 메모리를 사용합니다.
Starky는 SNARK 프레임워크보다 메모리 효율성이 10배 이상 높습니다. 부분적으로는 더 적은 행을 사용하기 때문입니다.
보조 제목
CPU 사용률
4KB 사전 이미지 입력에 대한 증명 생성 중 SHA-256의 평균 CPU 사용률을 측정하여 각 증명 시스템의 병렬화 정도를 평가합니다. 아래 표는 Linux Server(코어 20개) 및 Macbook M 1 Pro(코어 10개)의 평균 CPU 사용률(괄호 안의 코어당 평균 사용률)을 보여줍니다.
주요 관찰 내용은 다음과 같습니다.
Gnark 및 rapidsnark는 Linux 서버에서 가장 높은 CPU 사용률을 나타내며 여러 코어를 효율적으로 사용하고 증명 생성을 병렬화할 수 있음을 나타냅니다. Halo 2도 좋은 병렬화 성능을 보여주었습니다.
Linux 서버에서 대부분의 프레임워크의 CPU 사용률은 snarkjs를 제외하고 Macbook Pro M 1의 두 배입니다.
첫 번째 레벨 제목
결론 및 향후 연구
이 기사는 다양한 zk-SNARK 및 zk-STARK 개발 프레임워크에서 SHA-256의 성능 테스트 결과를 종합적으로 비교합니다. 비교를 통해 SHA-256 작업에 대한 간결한 증명을 생성해야 하는 개발자를 돕기 위해 각 프레임워크의 효율성과 유용성에 대한 통찰력을 얻습니다. 우리는 Groth 16 프레임워크(예: rapidsnark, gnark)가 Plonk 프레임워크(예: Halo 2, Plonky 2)보다 증명 생성 속도가 더 빠르다는 것을 발견했습니다. Plonkish 산술의 조회 테이블은 더 큰 사전 이미지 크기를 사용할 때 SHA-256 제약 조건과 증명 시간을 크게 줄입니다. 또한 gnark 및 rapidsnark는 여러 코어를 활용하여 작업을 병렬화하는 탁월한 기능을 보여줍니다. 반면에 Starky의 증명 생성 시간은 훨씬 더 짧은 증명 크기의 비용으로 훨씬 더 짧습니다. 메모리 효율성 측면에서 rapidsnark와 Starky는 다른 프레임워크보다 성능이 뛰어납니다.
영지식 증명 평가 플랫폼 "Pantheon" 구축의 첫 단계로, 이번 성능 테스트 결과가 최종적으로 구축하고자 하는 종합 테스트 플랫폼이 되기에는 거리가 멀다는 점을 인정합니다. 우리는 피드백과 비판을 환영하고 환영하며 개발자가 영지식 증명에 더 쉽게 접근하고 진입 장벽을 낮추기 위한 이 이니셔티브에 모든 사람이 기여하도록 초대합니다. 또한 대규모 성능 테스트를 위한 컴퓨팅 리소스 비용을 충당하기 위해 개인 독립 기여자에게 보조금을 기꺼이 제공할 것입니다. 우리는 함께 ZKP의 효율성과 유용성을 개선하고 커뮤니티에 더 광범위하게 혜택을 줄 수 있기를 바랍니다.
마지막으로 성능 테스트 결과에 대한 소중한 리뷰와 피드백을 주신 Polygon Zero 팀, Consensys의 gnark 팀, Pado Labs, Delphinus Lab 팀에게 감사드립니다.
IOS
Android