"암호학의 주류 학문"으로 떠오른 제로지식 증명(ZKP)에 대한 비판
*참고: 우선 이것은 한 시간 만에 작성한 초안입니다. 주로 정보를 빠르게 수집하기 위한 것이므로 잠재적인 오류와 불완전한 정보가 매우 많을 수 있습니다.
ZK에 대한 주요 비판은 두 가지입니다:
-
첫째, 증명 생성 시간이 길다는 점 (때문에 다양한 벤치마크, 새로운 ZK 프로토콜, 하드웨어 최적화 기술들이 존재함);
-
둘째, 시스템 및 애플리케이션 보안이 여전히 검증 단계에 있다는 점입니다.
증명 생성 성능
제로지식 증명(ZK)은 블록체인 분야에서 매우 인기 있는 기술입니다. 체인 상의 계산 자원은 부족하고 비용이 많이 들기 때문에, ZK는 이러한 계산을 오프체인에서 수행할 수 있게 해줍니다. 비록 오프체인에서의 증명 생성에 많은 시간이 소요되지만, 이는 결국 최종 증명과 관련된 검증 계산을 압축하여 마치 계산이 "체인 상에서" 이루어진 것처럼 만들어 줍니다.
ZK 증명 생성 시간이 너무 길다는 문제는 본질적으로 ZK가 감수해야 하는 트레이드오프이기 때문에 연구자들과 개발자들에 의해 종종 간과됩니다.
그들은 이 단점을 직접 비판하지는 않지만, 그 해결책에 대해 다양한 방법론과 논의들을 제시합니다.
즉, 다양한 솔루션을 제안하고 광범위한 벤치마킹을 수행함으로써 ZK의 지나치게 긴 증명 시간 문제를 암묵적으로 다룹니다.
a) 벤치마크
ZK 애플리케이션의 성능을 측정하기 전에, 먼저 ZK 프로토콜의 기본 구성 요소인 커밋먼트(Commitment)의 성능을 테스트해야 합니다.
예를 들어 FRI는 STARK를 가능하게 하고, KZG는 일반적인 SNARK를, IPA는 Bulletproof를 가능하게 합니다. 이러한 저수준 커밋먼트의 성능 테스트는 ZK 애플리케이션 성능에는 직관적이지 않을 수 있지만, ZK의 긴 증명 시간 문제를 이해하는 데 큰 도움이 됩니다.
위 링크에서 알 수 있듯이, 이러한 저수준 커밋먼트 프로토콜은 계산 복잡성이 높아 증명 시간이 길어질 수 있을 뿐 아니라, 메모리 소비도 매우 크다는 문제가 있습니다.
물론 메모리 소비는 주로 하드웨어 구성 요구사항과 관련이 있으며, 오늘 우리가 다루는 주제와는 다소 거리가 있습니다.
구체적인 SNARK 성능 테스트에 대해서는 a16z crypto가 이를 프런트엔드와 백엔드로 구분합니다:
-
프런트엔드는 ZK 애플리케이션 개발자가 접하는 Cairo 언어 또는 zkVM 고급 언어 등;
-
백엔드는 SNARK 증명 생성 시간과 더 밀접한 관계가 있는 커밋 등 저수준 암호학 연산을 의미합니다.
저자는 SNARK 증명 생성 과정에 약 100배의 계산 오버헤드가 발생하며, 각 ZK 프로토콜마다 추가적인 오버헤드가 있다고 언급합니다. 예를 들어:
"Groth16에서는 증명자(P)가 쌍(pairing) 친화적인 군 위에서 작업해야 하는데, 이 군의 연산은 일반적으로 쌍이 아닌 군보다 최소 2배 이상 느립니다. 이로 인해 앞서 언급한 100-|C| 추정치보다 최소 6배 이상 추가로 느려집니다."
전반적으로 zk-SNARK의 추가적인 성능 오버헤드는 대략 200~1000배 정도의 범위에 있다고 말할 수 있습니다.
또한 이 글은 zk-SNARK의 다른 제약 사항들, 즉 신뢰 설정(trusted setup)과 메모리 사용량 등도 언급합니다.
Modulus Labs의 글은 일부 ZK 프로토콜의 실제 성능을 측정했습니다. 일부 벤치마크는 파라미터 수에 기반한 것으로, 직관적이지는 않습니다. 그러나 애플리케이션 측면에서 Worldcoin의 사례를 보면, 가장 빠르다고 알려진 Plonky2를 사용하더라도 증명 생성에 몇 분이 걸리고 수십 GB의 메모리를 소모해 개인 컴퓨터에서는 실행할 수 없습니다.
b) 재귀와 배치 처리
증명 생성 시간을 줄이기 위해 여러 증명을 병렬로 생성할 수 있습니다.
일반적으로 이를 위한 두 가지 방법이 있습니다: 하나는 배치 처리(batching), 다른 하나는 재귀(recursion)입니다.
간단히 말해, 배치 처리란 여러 증명을 동시에 생성한 후 하나로 통합하는 것이고, 재귀는 하나의 증명 안에서 다른 증명들을 검증하는 방식입니다. 일반적으로 재귀 방식은 증명 크기도 더욱 작게 유지할 수 있는 장점이 있습니다.
더 널리 사용되는 집계(aggregation) 방법으로는 Halo2, Plonky2 등이 있습니다. 이들은 각각 다른 방식으로 배치 처리와 재귀를 구현하여 증명 시간을 줄이고 있습니다.
ZK의 프로토콜 계층뿐 아니라 애플리케이션 계층에서도 특화된 최적화가 가능합니다. 예를 들어, STARK와 SNARK를 동시에 사용하거나, 매크로 차원에서 재귀 전략을 취해 애플리케이션별로 맞춤 조정할 수 있습니다.
일반적으로 이러한 접근은 프로토콜 및 증명 분배 측면에서 증명 생성 시간을 실제로 줄여줍니다. 새로운 ZK 프로토콜을 탐색할 때, 증명 시간 단축은 가장 중요한 고려 사항 중 하나입니다.
c) 하드웨어 가속
또한 물리적 장치와 노드 수준에서 ZK 애플리케이션의 증명 시간을 더욱 줄이기 위한 하드웨어 측면의 노력도 활발합니다.
우선 앞서 언급한 새로운 프로토콜과 마찬가지로, HyperPlonk과 같이 가능한 한 하드웨어 친화적으로 설계된 ZK 프로토콜들이 등장하고 있습니다.
Paradigm은 ZK 증명 생성 속도가 느린 주된 이유가 MSM(Multi-Scalar Multiplication)과 FFT(Fast Fourier Transform)와 같은 대규모 연산 때문이며, 이들이 하드웨어에 적합하지 않아 무작위 메모리 접근 등의 문제로 인해 결국 증명 생성이 느려진다고 지적합니다. 이러한 저수준 암호 계산을 위해 ZK 프로토콜은 구성과 규모 면에서 하드웨어 친화성을 높이기 위한 트레이드오프가 필요합니다.
몇몇 ZK 하드웨어 가속 업체들은 현재 GPU가 가장 경제적이며 유연하게 구성 가능한 하드웨어 선택이라고 말하며, 장기적으로는 FPGA에서 ASIC 단계로 전환될 것이라고 전망합니다. ZK 하드웨어 회사들의 주장에 따르면, 첫 번째 버전의 ASIC은 ZK 증명 생성 시간을 최소 30% 이상 직접 줄일 수 있습니다.
또한 서로 다른 서버 구성으로 인해, 클라우드 서버를 노드로 운영할 경우 하드웨어별 최적화가 달라질 수 있습니다.
보안
현재 ZK에 대한 또 다른 비판은 회로 코드 자체가 여전히 정확해야 한다(bug 없어야 함)는 점입니다.
ZK 프로토콜이 건전성(soundness), 완전성(completeness), 제로지식성(zero-knowledge) 측면에서 공격받는다면, 우리는 더 이상 유효한 ZK 시스템을 갖지 못하게 됩니다. 이 링크에서 다양한 공격 시나리오를 확인할 수 있습니다.
ZK 애플리케이션이 '신뢰 없음(trustless)'이라 불릴 수는 있지만, 여전히 해당 프로젝트의 ZK 프로토콜과 애플리케이션 코드 및 아키텍처가 올바른지 확인해야 합니다. 블록체인 분야에는 다양한 ZK 관련 오류 사례가 존재합니다. 예를 들어 zkEVM의 경우 ZK 회로 코드베이스가 방대하기 때문에, 비탈릭(Vitalik)은 ZK 애플리케이션에 다중 증명자(multi-prover)가 필요하다고 언급한 바 있습니다.
따라서 ZK 시스템은 형식적 검증(formal verification)과 같은 보안 도구 또는 Ecne과 같은 기타 보안 관련 도구들과 함께 사용되어야 할 수 있습니다. 애플리케이션 차원에서는 특히 zkEVM과 같은 대규모 프로젝트의 경우 더욱 철저한 감사(audit)가 필요합니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
msfew / Suning Yao
