Celer: 만신전(Pantheon) - ZKP 개발 프레임워크 평가 플랫폼
지난 몇 달간 우리는 zk-SNARK 간결한 증명을 활용하는 최첨단 인프라를 개발하기 위해 많은 시간과 노력을 투자했습니다. 이 차세대 혁신 플랫폼은 개발자가 전례 없는 새로운 블록체인 애플리케이션 패러다임을 구축할 수 있게 해줍니다.
개발 과정에서 우리는 다양한 제로지식 증명(ZKP) 개발 프레임워크를 시험하고 사용했습니다. 이 여정은 매우 유익했지만, 동시에 특정 용도와 성능 요구 사항에 가장 적합한 프레임워크를 찾고자 하는 신규 개발자들이 다양한 ZKP 프레임워크들 사이에서 혼란을 겪을 수 있다는 점도 깊이 인식하게 되었습니다. 이러한 문제점을 고려하여, 포괄적인 성능 테스트 결과를 제공하는 커뮤니티 기반 평가 플랫폼의 필요성을 느꼈으며, 이를 통해 이러한 새로운 애플리케이션들의 개발 속도를 크게 가속화할 수 있을 것이라 판단했습니다.
이러한 필요성에 부응해, 우리는 공익적 커뮤니티 이니셔티브로서 제로지식 증명 개발 프레임워크 평가 플랫폼 「만신전 Pantheon」을 출시합니다. 이 이니셔티브의 첫 번째 단계는 커뮤니티가 다양한 ZKP 프레임워크의 재현 가능한 성능 테스트 결과를 공유하도록 장려하는 것입니다. 궁극적으로 저수준 회로 개발 프레임워크, 고수준 zkVM 및 컴파일러, 심지어 하드웨어 가속 제공업체까지 포함하는 광범위하게 인정받는 평가 플랫폼을 공동으로 구축하고 유지 관리하는 것이 목표입니다. 이를 통해 개발자들은 프레임워크 선택 시 더 많은 성능 비교 자료를 바탕으로 결정을 내릴 수 있게 되며, ZKP의 보급이 더욱 촉진되기를 바랍니다. 또한 일관된 기준의 성능 테스트 결과를 제공함으로써 ZKP 프레임워크 자체의 지속적인 업그레이드와 반복 개선을 유도하고자 합니다. 우리는 이 계획에 적극적으로 투자할 것이며, 뜻을 함께하는 모든 커뮤니티 구성원들을 초대하여 이 작업에 기여해 주실 것을 요청합니다!
첫 번째 단계: SHA-256을 이용한 회로 프레임워크 성능 테스트
본 글에서는 ZKP 만신전(Pantheon) 구축의 첫걸음을 내딛어, 일련의 저수준 회로 개발 프레임워크에서 SHA-256을 활용한 재현 가능한 성능 테스트 결과를 제공합니다. 다른 성능 테스트 입자도 가능하다는 점을 인정하지만, SHA-256은 블록체인 시스템, 디지털 서명, zkDID 등 광범위한 ZKP 사용 사례에 적합하기 때문에 이를 선택하였습니다.
또한 참고로, 저희 시스템에서도 SHA-256을 사용하고 있기 때문에 테스트가 편리했다는 점도 있습니다! 😂
우리는 다양한 zk-SNARK 및 zk-STARK 회로 개발 프레임워크에서 SHA-256의 성능을 평가했습니다. 이를 통해 각 프레임워크의 효율성과 실용성에 대한 통찰을 제공하고자 하며, 개발자들이 최적의 프레임워크를 선택하는 데 도움이 되기를 기대합니다.
증명 시스템
최근 몇 년간 제로지식 증명 시스템이 급격히 증가했습니다. 해당 분야의 모든 진보를 따라잡기는 어려운 일이며, 우리는 성숙도와 개발자 채택률을 기준으로 다음 증명 시스템들을 테스트 대상으로 선별했습니다. 다양한 프론트엔드/백엔드 조합을 대표적으로 보여주는 것을 목표로 했습니다.
-
Circom + snarkjs / rapidsnark: Circom은 회로 작성 및 R1CS 제약 생성을 위한 인기 있는 DSL이며, snarkjs는 Circom을 위한 Groth16 또는 Plonk 증명을 생성할 수 있습니다. rapidsnark 역시 Circom의 증명 생성기로, Groth16 증명을 생성하며 ADX 확장을 사용해 snarkjs보다 일반적으로 훨씬 빠르게 동작하고, 증명 생성을 가능한 한 병렬화합니다.
-
gnark: gnark는 Consensys에서 제공하는 종합적인 Golang 프레임워크로, Groth16, Plonk 및 기타 고급 기능들을 지원합니다.
-
Arkworks: Arkworks는 zk-SNARK를 위한 종합적인 Rust 프레임워크입니다.
-
Halo2 (KZG): Halo2는 Zcash에서 개발한 Plonk 기반의 zk-SNARK 구현입니다. 고도로 유연한 Plonkish 산술을 갖추고 있으며, 사용자 정의 게이트 및 조회 테이블과 같은 유용한 원시 연산들을 지원합니다. 본 테스트에서는 이더리움 재단과 Scroll이 지원하는 KZG 기반의 Halo2 포크 버전을 사용했습니다.
-
Plonky2: Plonky2는 Polygon Zero에서 개발한 PLONK 및 FRI 기술 기반의 SNARK 구현입니다. 작은 Goldilocks 필드를 사용하며 효율적인 재귀를 지원합니다. 본 성능 테스트에서는 100비트 추정 보안을 목표로 하고, 증명 생성 시간이 최적화되는 파라미터를 사용했습니다. 구체적으로 28개의 Merkle 조회, 8배 증폭 계수, 16비트 작업 증명 난이도를 사용하였으며, num_of_wires = 60 및 num_routed_wires = 60으로 설정했습니다.
-
Starky: Starky는 Polygon Zero의 고성능 STARK 프레임워크입니다. 본 성능 테스트에서는 100비트 추정 보안을 목표로 하고, 증명 시간이 최적화되는 파라미터를 사용했습니다. 구체적으로 90개의 Merkle 조회, 2배 증폭 계수, 10비트 작업 증명 난이도를 사용했습니다.
아래 표는 위에서 언급한 프레임워크들과 본 성능 테스트에서 사용한 관련 설정을 요약한 것입니다. 이 목록은 포괄적이지 않으며, 향후 Nova, GKR, Hyperplonk과 같은 최첨단 프레임워크/기술들도 추가로 연구할 예정입니다.
주의하세요: 이 성능 테스트 결과는 회로 개발 프레임워크에만 적용됩니다. 향후 별도의 기사에서 Scroll, Polygon zkEVM, Consensys zkEVM, zkSync, Risc Zero, zkWasm 등의 다양한 zkVM과 Noir, zkLLVM과 같은 IR 컴파일러 프레임워크에 대한 성능 테스트를 발표할 계획입니다.
성능 평가 방법론
이러한 다양한 증명 시스템의 성능을 평가하기 위해, N바이트 데이터의 SHA-256 해시 값을 계산했습니다. 여기서 N = 64, 128, ..., 64K 범위에서 실험을 수행했습니다(Starky의 경우, 입력은 고정된 64바이트지만 메시지 블록의 총 수는 동일하게 유지됨). 성능 코드 및 SHA-256 회로 설정은 이 저장소에서 확인할 수 있습니다.
또한, 각 시스템의 성능을 다음과 같은 지표를 기준으로 평가했습니다:
-
증명 생성 시간(위트니스 생성 시간 포함)
-
증명 생성 중 최대 메모리 사용량
-
증명 생성 중 평균 CPU 사용률(%). (이 지표는 증명 생성 과정의 병렬화 정도를 반영함)
참고로, 증명 크기와 증명 검증 비용은 상쇄 가능하다고 판단하여 일부 "임의적인" 가정을 두었습니다. 왜냐하면 체인에 올리기 전에 Groth16 또는 KZG와 결합함으로써 완화될 수 있기 때문입니다.
테스트 머신
성능 테스트는 두 대의 서로 다른 머신에서 수행되었습니다:
-
Linux 서버: 20코어 @2.3GHz, 384GB 메모리
-
Macbook M1 Pro: 10코어 @3.2GHz, 16GB 메모리
Linux 서버는 다수의 CPU 코어와 풍부한 메모리를 갖춘 환경을 시뮬레이션하기 위한 것이며, Macbook M1 Pro는 일반적인 개발 환경으로 더 강력한 CPU를 갖지만 코어 수는 적습니다.
선택적 멀티스레딩은 활성화했으나, 본 성능 테스트에서는 GPU 가속을 사용하지 않았습니다. 향후 GPU 성능 테스트를 진행할 예정입니다.
성능 평가 결과
제약 조건 수
자세한 성능 결과를 논의하기 전에, 각 증명 시스템에서 SHA-256의 복잡성을 이해하기 위해 제약 조건 수를 살펴보는 것이 유용합니다. 중요한 점은 서로 다른 산술 방식 간의 제약 조건 수를 직접 비교할 수 없다는 것입니다.
다음 결과는 64KB의 원상 이미지 크기에 해당합니다. 다른 원상 크기에 따라 결과는 달라질 수 있으나, 대략적으로 선형 스케일링됩니다.
-
Circom, gnark, Arkworks 모두 동일한 R1CS 알고리즘을 사용하며, 64KB SHA-256 계산 시 R1CS 제약 조건 수는 대략 30M~45M 범위입니다. Circom, gnark, Arkworks 간의 차이는 설정 차이에서 기인할 수 있습니다.
-
Halo2와 Plonky2는 모두 Plonkish 산술을 사용하며, 행 수는 2^22에서 2^23 범위입니다. 조회 테이블을 사용함으로써 Halo2의 SHA-256 구현은 Plonky2보다 훨씬 효율적입니다.
-
Starky는 AIR 알고리즘을 사용하며, 실행 추적 테이블에는 2^16개의 전이 단계가 필요합니다.
증명 생성 시간
[그림 1] Linux 서버에서 다양한 원상 이미지 크기에 대해 각 프레임워크의 SHA-256 증명 생성 시간을 테스트했습니다. 다음과 같은 발견을 할 수 있었습니다:
-
SHA-256의 경우, Groth16 프레임워크(rapidsnark, gnark, Arkworks)는 Plonk 프레임워크(Halo2, Plonky2)보다 증명 생성이 더 빠릅니다. 그 이유는 SHA-256이 주로 비트 연산으로 구성되어 있어 선 값이 0 또는 1이 되기 때문입니다. Groth16의 경우, 이는 타원 곡선 스칼라 곱셈에서 타원 곡선 점 덧셈으로의 대부분의 계산을 줄입니다. 그러나 Plonk에서는 선 값이 계산에 직접 사용되지 않기 때문에, SHA-256의 특수한 선 구조가 Plonk 프레임워크의 계산량 감소에 기여하지 않습니다.
-
모든 Groth16 프레임워크 중에서 gnark와 rapidsnark는 Arkworks 및 snarkjs보다 5~10배 더 빠릅니다. 이는 여러 코어를 활용해 증명 생성을 병렬화하는 능력이 뛰어나기 때문입니다. gnark는 rapidsnark보다 25% 더 빠릅니다.
-
Plonk 프레임워크의 경우, >=4KB의 큰 원상 크기를 사용할 때 Plonky2의 SHA-256은 Halo2보다 50% 느립니다. 그 이유는 Halo2의 구현이 주로 조회 테이블을 사용해 비트 연산을 가속화하여 Plonky2보다 2배 적은 행 수를 가지기 때문입니다. 하지만 동일한 행 수를 갖는 Plonky2와 Halo2를 비교하면(예: Halo2의 2KB 이상 SHA-256 vs Plonky2의 4KB 이상 SHA-256), Plonky2는 Halo2보다 50% 빠릅니다. 만약 Plonky2에서도 조회 테이블을 사용해 SHA-256을 구현한다면, 증명 크기는 더 커지겠지만 Halo2보다 더 빨라질 것으로 기대됩니다.
-
반면, 입력 원상 크기가 작을 때(<=512바이트), 조회 테이블의 고정 설정 비용이 대부분의 제약을 차지하므로 Halo2가 Plonky2(및 다른 프레임워크들)보다 느립니다. 그러나 원상 크기가 커짐에 따라 Halo2의 성능은 경쟁력 있게 변하며, 최대 2KB 크기까지 증명 생성 시간이 거의 일정하게 유지되고, 이후 거의 선형적으로 확장됩니다.
-
예상대로 Starky의 증명 생성 시간은 어떤 SNARK 프레임워크보다 훨씬 짧습니다(5~50배). 다만 이는 더 큰 증명 크기를 대가로 합니다.
-
또한 주목할 점은, 회로 크기가 원상 크기에 선형적으로 비례하더라도, SNARK의 증명 생성은 O(nlogn) FFT로 인해 초선형적으로 증가한다는 점입니다(로그 스케일로 인해 그래프상으로는 명확하지 않을 수 있음).
Macbook M1 Pro에서도 증명 생성 시간 성능 테스트를 수행했습니다([그림 2] 참조). 그러나 arm64 아키텍처에 대한 지원 부족으로 인해 rapidsnark는 해당 테스트에 포함되지 않았습니다. arm64에서 snarkjs를 사용하기 위해 WebAssembly로 위트니스를 생성해야 했으며, 이는 Linux 서버에서 사용된 C++ 위트니스 생성보다 느립니다.
Macbook M1 Pro에서 테스트를 수행하면서 추가로 관찰된 점은 다음과 같습니다:
-
Starky를 제외한 모든 SNARK 프레임워크는 원상 크기가 커질수록 메모리 부족(OOM) 오류 또는 스왑 메모리 사용(증명 시간 지연) 현상을 겪습니다. 구체적으로 Groth16 프레임워크(snarkjs, gnark, Arkworks)는 원상 크기 >=8KB부터 스왑 메모리를 사용하기 시작하며, gnark는 >=64KB에서 OOM 발생, Halo2는 >=32KB에서 메모리 제한에 부딪히며, Plonky2는 >=8KB부터 스왑 메모리를 사용합니다.
-
FRI 기반 프레임워크(Starky 및 Plonky2)는 Macbook M1 Pro에서 Linux 서버보다 약 60% 더 빠릅니다. 반면 다른 프레임워크들은 두 기계에서 증명 시간이 유사합니다. 따라서 Plonky2가 조회 테이블을 사용하지 않더라도 Macbook M1 Pro에서 Halo2와 거의 동일한 증명 시간을 달성합니다. 주된 이유는 Macbook M1 Pro가 더 강력한 CPU를 갖지만 코어 수가 적기 때문입니다. FRI는 주로 해시 연산을 수행하며 CPU 클럭 사이클에 민감하지만, KZG나 Groth16만큼 병렬화되지 않습니다.
메모리 사용 피크
[그림 3]과 [그림 4]는 각각 Linux 서버와 Macbook M1 Pro에서 증명 생성 중 최대 메모리 사용량을 보여줍니다. 이 테스트 결과로부터 다음과 같은 관측이 가능합니다:
-
모든 SNARK 프레임워크 중에서 rapidsnark가 가장 메모리 효율적입니다. 또한 조회 테이블의 고정 설정 비용으로 인해 원상 크기가 작을 때 Halo2가 더 많은 메모리를 사용하지만, 원상 크기가 커질수록 전체적으로 소비되는 메모리가 적어지는 것을 확인할 수 있습니다.
-
Starky는 SNARK 프레임워크보다 10배 이상 메모리 효율성이 높습니다. 부분적으로는 더 적은 행 수를 사용하기 때문입니다.
-
스왑 메모리 사용으로 인해 원상 크기가 커질수록 Macbook M1 Pro의 메모리 사용량 피크는 상대적으로 안정적입니다.
CPU 사용률
각 증명 시스템의 병렬화 정도를 평가하기 위해, 4KB 원상 입력에 대한 SHA-256 증명 생성 중 평균 CPU 사용률을 측정했습니다. 아래 표는 Linux 서버(20코어) 및 Macbook M1 Pro(10코어)에서의 평균 CPU 사용률을 나타냅니다(괄호 안은 코어당 평균 사용률).
주요 관측 결과는 다음과 같습니다:
-
gnark와 rapidsnark는 Linux 서버에서 가장 높은 CPU 사용률을 보이며, 다중 코어를 효과적으로 활용하고 증명 생성을 병렬화할 수 있음을 나타냅니다. Halo2 역시 우수한 병렬화 성능을 보입니다.
-
대부분의 프레임워크는 Linux 서버에서의 CPU 사용률이 Macbook M1 Pro의 2배 정도인데, snarkjs만이 예외입니다.
-
초기에는 FRI 기반 프레임워크(Plonky2 및 Starky)가 다중 코어를 효과적으로 활용하기 어렵다고 예상되었지만, 실제 성능 테스트에서는 일부 Groth16 또는 KZG 프레임워크보다 나쁘지 않았습니다. 100개 이상의 코어를 갖는 머신에서 CPU 사용률에 차이가 나는지는 아직 관찰되지 않았습니다.
결론 및 향후 연구
본 글은 다양한 zk-SNARK 및 zk-STARK 개발 프레임워크에서 SHA-256의 성능을 포괄적으로 비교했습니다. 이를 통해 각 프레임워크의 효율성과 실용성에 대한 깊은 통찰을 얻었으며, SHA-256 작업을 위한 간결한 증명 생성이 필요한 개발자들에게 도움이 되기를 바랍니다.
우리는 Groth16 프레임워크(예: rapidsnark, gnark)가 Plonk 프레임워크(예: Halo2, Plonky2)보다 증명 생성 속도가 더 빠르다는 것을 발견했습니다. Plonkish 산술에서 조회 테이블은 큰 원상 크기를 사용할 때 SHA-256의 제약 조건 수와 증명 시간을 크게 줄입니다. 또한 gnark와 rapidsnark는 다중 코어를 활용해 병렬 처리하는 뛰어난 능력을 보여주었습니다. 반면, Starky는 증명 생성 시간이 훨씬 짧지만, 그 대가로 증명 크기가 훨씬 큽니다. 메모리 효율성 측면에서는 rapidsnark와 Starky가 다른 프레임워크들을 능가합니다.
「만신전 Pantheon」이라는 제로지식 증명 평가 플랫폼 구축의 첫 걸음으로서, 이번 성능 테스트 결과는 우리가 궁극적으로 만들고자 하는 종합적인 테스트 플랫폼과는 거리가 멀다는 점을 인정합니다. 우리는 피드백과 비판을 환영하며, ZKP를 더 쉽게 접근하고 사용할 수 있도록 이 이니셔티브에 기여해 주실 모든 분들을 초대합니다. 또한 대규모 성능 테스트를 위한 컴퓨팅 리소스 비용을 부담하기 위해 개인 기여자에게 자금 지원도 제공할 의향이 있습니다. 함께 ZKP의 효율성과 실용성을 높이고, 더 넓은 커뮤니티에 이익을 제공할 수 있기를 바랍니다.
마지막으로, 성능 테스트 결과에 대한 귀중한 검토와 피드백을 제공해주신 Polygon Zero 팀, Consensys의 gnark 팀, Pado Labs 및 Delphinus Lab 팀께 감사드립니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
