클라이언트 제로 지식 증명: 도전과 해결책
원문 제목:ZKP on the Client-side: Challenges \& Our Solutions
TLDR
클라이언트에서 좋은 제로 지식 증명 시스템을 구축하는 것은 생각보다 훨씬 더 어렵습니다. 그러나 ZKP가 발전함에 따라 클라이언트에서 ZKP를 생성하고 체인에서 검증하는 것이 가능해졌습니다. 2024년은 클라이언트 제로 지식 증명 시스템이 대중의 시야에 들어오는 해가 될 것입니다. 이 글에서는 기술적인 관점에서 클라이언트 제로 지식 증명이 왜 이렇게 어려운지, 그리고 OpenID3가 어떻게 이러한 도전을 해결하는지에 대해 설명하겠습니다.
탈중앙화 소셜 네트워크, 전체 체인 게임, 프라이버시 인증 및 프라이버시 KYC/AML, 새로운 DeFi 애플리케이션을 포함한 Web3 분야에서 클라이언트 제로 지식 증명은 매우 중요한 인프라를 제공할 것입니다.
저는 OpenID3의 암호 엔지니어입니다. OpenID3는 클라이언트 제로 지식 증명의 선구자 중 하나로서, 이 블로그에서 클라이언트 제로 지식 증명이 왜 이렇게 어려운지 간단히 이야기하고, OpenID3가 이러한 문제를 어떻게 해결하는지에 대해 이야기하고자 합니다.
제로 지식 증명 시스템을 구축하는 것은 어떤 경험인가?
오늘날 우리가 가진 제로 지식 증명 시스템(ZKP)은 주로 이더리움의 확장을 지원합니다. 발전해온 결과, 정말 멋진 클라이언트 애플리케이션들이 있지만, 대부분은 다른 시스템에서 운영되거나 간단한 회로로 구성되어 있거나 사용자 경험에 그다지 신경을 쓰지 않습니다.
제가 산업 행사에 참석할 때 ZKP 엔지니어라고 소개하면 가장 흔한 반응은 제가 zkSync에서 일하는지, 아니면 우리가 또 다른 zkRollup Layer2를 구축하고 있는지에 대한 질문입니다. 한동안 이 질문이 좀 귀찮아졌습니다. 이는 마치 내가 싱가포르에 살고 있다고 말하면 사람들이 정말로 채찍질이 있는지 묻는 것과 비슷합니다. 어쨌든, 여기의 상황을 대략적으로 설명하고 싶습니다: 대부분의 ZKP 시스템은 클라이언트 애플리케이션을 위해 구축되지 않았습니다.
왜 그럴까요? 몇 가지 주요 고려 사항이 있으며, 제가 엔지니어들이 고려하는 중요한 방향에 대해 깊이 들어가기 전에 ZKP의 기본 구성 요소 몇 가지를 소개하겠습니다.
- Prover/Verifier 증명자와 검증자: 간단히 말해, 증명자 프로그램은 특정 프로그램과 해당 입력을 증명하기 위해 많은 계산 자원을 소모하여 검증자 프로그램이 증명자가 정직하다는 것을 간단하고 빠르게 증명할 수 있도록 합니다. 대부분의 ZKP 시스템에서 검증자는 일반적으로 스마트 계약입니다.
- Circuit \& Witness 회로와 증인: 증명자가 가진 정보는 증인이라고 하며, 정의된 프로그램은 회로라고 합니다. 주어진 회로와 증인으로 증명을 생성할 수 있습니다.
- Public \& Private Witness 공개 증인과 비공개 증인: 회로를 구축할 때 증인은 기본적으로 비공개이며, 특정 상황에서는 일부 정보가 공개로 표시됩니다. 이러한 공개 정보는 검증자가 회로를 검증하거나 스마트 계약의 논리를 실행하는 데 도움이 됩니다.
- Application \& Aggregation Proof 애플리케이션 증명과 집합 증명: 대부분의 ZKP는 집합이 필요합니다. 여러 애플리케이션 증명을 집합하면 집합 증명이 생성됩니다. 집합 증명은 검증자가 ZKP를 일괄 검증할 수 있게 하여 가스 비용을 절약하고 체인상의 정보 오염을 줄일 수 있습니다.
이제 이러한 기본 개념을 이해한 후, ZKP 엔지니어는 일반적으로 다음과 같은 사항을 고려합니다:
- Prover Time \& Memory Consumption 증명자 시간 및 메모리 소비
- Verifier Cost: 검증자 비용.
- Size 크기: 파일 및 키 크기는 여러 종류를 포함합니다:
- Proof Size 증명 크기, 일반적으로 가스 비용과 정비례합니다.
- Executable Size: 패키징된 프로그램 크기
- Parameter Size: 일부 ZKP 시스템은 신뢰할 수 있는 설정을 요구하며, 신뢰할 수 있는 설정 파일 크기는 회로 복잡도와 정비례합니다.
- Key Size: 키 크기. 일부 검증 시스템의 증명자 키는 매우 클 수 있습니다. OpenID3의 초기에는 Halo2를 사용하여 회로를 구축하려고 했으며, 생성된 증명자 키는 3GB에 달했습니다.
클라이언트 ZKP
zkRollup 증명 시스템과 전형적인 클라이언트 증명 시스템은 우선 순위가 다릅니다. 마찬가지로, 타협하지 않으면 모든 장점을 실현하기가 일반적으로 어렵습니다. ZKP는 클라이언트와 서버 측에서 본질적으로 다릅니다. 일반적으로 zkRollup 증명 시스템은 서버 측에서 실행되며 거의 무한한 계산 자원과 초고속 네트워크를 사용할 수 있습니다. 그러나 클라이언트에서는 계산 자원이 매우 제한적이며, 사용자 네트워크는 매우 불안정할 가능성이 높고, 사용자는 웹 페이지를 기다리며 지속적으로 새로 고침할 인내심이 없습니다.
따라서:
- 증명자 시간 및 메모리 소비는 클라이언트 ZKP의 최우선 사항이며, 서버 측에서는 훨씬 관대합니다.
- 파일 크기. 우리가 작성한 일부 회로의 경우 신뢰할 수 있는 매개변수가 20MB에 이를 수 있으며, 일부 ZKP 시스템에서 생성된 WASM 실행 파일은 수백 MB에 이를 수 있습니다. 우리는 이러한 파일을 고객에게 전송할 수 없으며, 고객이 다운로드 파일을 기다리는 긴 시간을 인내할 것이라고 기대할 수 없습니다. 3MB를 초과하는 실행 파일, 키, 매개변수는 사용자가 수용하기 어려울 것입니다.
- 체인 검증 비용. Rollup 검증 비용은 대량의 사용자가 분담할 수 있지만, 클라이언트 ZKP 증명은 일반적으로 각 사용자에게 비용을 부담해야 합니다.
- 지연. zkRollup은 각 블록에 대해 집합 증명 계산을 수행할 필요가 없지만, 클라이언트 ZKP는 시스템이 완료될 수 있는 경우 가능한 한 빨리 수행해야 합니다. 사용자는 증명을 체인에서 검증하기 위해 며칠을 기다리지 않을 것이며, 반대로 몇 분이 사용자가 수용할 수 있는 시간의 한계가 될 것입니다.
확실히 Rollup 방식의 ZKP 시스템을 구축하는 것은 매우 복잡한 일이지만, 기능적인 클라이언트 ZKP 시스템을 구축하는 것은 쉬운 일이 아니며, 실제로 시스템 기능에 대해 더 엄격한 요구를 제기합니다.
ZKP 시스템에 대한 생각
이러한 생각을 바탕으로 우리는 OpenID3의 구축을 시작했습니다. OpenID3는 ZKP 기반의 개방형 프로토콜로, 체인에서 사용자의 Web2 소셜 계정 소유권을 증명하는 데 사용됩니다. OpenID3는 클라이언트에서 사용자의 신원 증명을 수행한 후 ZKP를 공개 ZKP 집합기 네트워크에 게시하고 체인에 제출합니다. 이 과정에서 사용자의 모든 정보는 사용자 로컬을 떠나지 않으며, 저렴하고 효율적으로 체인에서 검증할 수 있습니다. 응용 시나리오는 다음과 같습니다:
- 허가 없는(Permissionless) 탈중앙화된 안전한 체인 사용자 Web2 신원.
- 탈중앙화된 자가 관리 소셜 로그인 지갑.
초기 테스트 버전은 Linea 네트워크에서 400,000개 이상의 신원 정보를 검증했습니다.
간단히 말해, 우리는 다음과 같은 성과를 달성했습니다:
- 클라이언트는 약 2MB 크기의 WASM 실행 파일을 다운로드합니다.
- 클라이언트는 약 30초 내에 애플리케이션 증명을 생성합니다.
- 그런 다음 클라이언트는 애플리케이션 증명을 일반 집합기 중 하나에 전달하고 대기열에 넣습니다. 집합기는 정기적으로 트리거됩니다. 집합기는 많은 메모리를 소모하고 약 3분 동안 증명을 집합하여 클라이언트에게 증명을 전달합니다. 집합기는 또한 증명의 모든 클라이언트 공개 입력을 Merkle 트리에 등록하고 트리 루트를 집합 증명의 공개 증인으로 공개합니다.
- 집합기는 체인에 집합 증명을 제출하며, 스마트 계약은 해당 증명을 검증하고 약 250,000 가스의 Merkle Tree 루트를 기록할 수 있습니다. (ETH에서 특정 ERC-20 토큰으로의 Uniswap 호출 가격에 해당합니다). 현재 하나의 증명에는 32-64개의 사용자 증명이 포함되어 있으며, 검증의 가스 비용은 이러한 사용자가 분담하여 각 사용자가 ZKP 검증에 지불하는 가스 비용은 기본적으로 한 번의 체인상의 ETH 전송과 유사합니다.
- 사용자는 "claim" 호출을 제출하고 Merkle 증명을 수행하여 해시 메시지를 사용하여 자신의 신원을 식별하고 증명된 ZKP를 자신의 주소에 연결합니다.
체인상의 주소와 사용자가 제출한 신원 해시 외에는 집합기, 스마트 계약 및 우리는 사용자 신원에 대해 아무것도 알지 못합니다.
어떻게 구현하고 개선할 것인가
이 부분은 다소 기술적일 수 있으며, 일부 ZKP 배경 지식이 필요합니다.
- 클라이언트에서는 Plonky2를 사용하기로 선택했습니다. 이는 FRI+Plonk를 사용하여 Goldilock의 ZKP 시스템입니다. 신뢰할 수 있는 설정이 필요 없고, 빠른 증명 시간과 합리적인 메모리 소비를 제공합니다. 우리는 신원을 검증하는 최소 요구 사항을 충족하기 위해 회로를 간소화했으며, 컴파일된 WASM blob은 약 3MB입니다.
- 집합기 측에서는 먼저 Plonky2 증명을 집합하여 많은 Plonky2 증명을 하나로 집합할 수 있는 "포장된" Plonky2 증명을 생성합니다. 이 증명은 올바른 회로 구조를 검증합니다(즉, 사용자가 우리의 예상대로 정확한 회로를 실행하고 공개 증인을 Merkle 트리로 압축하여 공간을 절약하는 등).
- Plonky2 집합 후, 우리는 Gnark 내부에서 Plonky2 검증기를 실행하여 증명과 검증자 키를 체인에서 빠르게 검증 가능한 형태로 변환합니다. Gnark 집합은 주요 시간 소모자로 약 2분 반이 소요됩니다.
- 마지막으로, 집합 증명을 통해 사용자는 일반 Plonky2+Gnark 검증자 계약을 사용하여 저렴한 비용으로 자신을 검증할 수 있으며, 단지 211,000 가스만 필요하며, 체인 호출 저장의 오버헤드를 더하여 검증 비용을 250,000 가스 이하로 통제할 수 있습니다.
현재 OpenID3의 ZKP 측에서는 두 가지 작업을 진행하고 있습니다:
- 우리는 GPU 가속 등의 기술을 통해 Gnark 집합 시간을 단축시키고자 하며, 목표는 30초 이하입니다.
- 우리는 실행 파일 크기를 추가로 최소화하기 위해 트리 의존성을 조정하고 있으며, 최선은 1MB 이하입니다.
마무리
클라이언트 ZKP는 탐험자가 너무 적은 분야이며, 우리는 우리가 취한 프로세스를 표준화하기 위해 다른 팀과 협력하기를 희망합니다.
- 프레임워크, DSL은 쉽게 구성할 수 있는 Plonky2 회로를 중심으로 구축될 수 있습니다.
- 우리는 아직 많은 프로세스에 대해 접기 최적화를 도입하지 않았으며, 집합 접기를 통해 큰 성능 향상을 기대하고 있습니다.
- 집합기 서비스 또는 일반 체인 검증 서비스를 구축할 수 있으며, 이는 ZKP의 미래에 중요한 인프라로 작용하여 더 큰 커뮤니티에 안전성, 탈중앙화 및 뛰어난 개발자 경험을 제공합니다.