クライアントのゼロ知識証明：課題と解決策
この記事では、技術的な観点からクライアントのゼロ知識証明がなぜ非常に困難であるか、そしてOpenID3がどのようにその課題を解決するかについて説明します。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は、ユーザーのWeb2ソーシャルアカウントの所有権をオンチェーンで証明するためのZKPに基づくオープンプロトコルです。OpenID3はクライアントでユーザーの身分証明書を証明し、その後ZKPをオープンなZKP集約ネットワークに公開し、オンチェーンに提出します。この間、ユーザーのすべての情報はユーザーのローカルに留まり、安価かつ効率的にオンチェーンで検証できます。アプリケーションシナリオには以下が含まれます：
- 無許可（Permissionless）で分散型の安全なオンチェーンユーザーのWeb2アイデンティティ。
- 分散型で自己管理型のソーシャルログインウォレット。
初期のテスト版は、Lineaネットワーク上で40万以上のアイデンティティ情報を検証しました。
簡単に言えば、私たちは以下の成果を達成しました：
- クライアントは約2MBのWASM実行ファイルをダウンロードします；
- クライアントは約30秒でアプリケーション証明を生成します；
- その後、クライアントはアプリケーション証明を一般的な集約器の1つに渡し、キューに入れます。集約器は定期的にトリガーされます。集約器は大量のメモリを消費し、約3分で証明を集約し、証明をクライアントに返します。集約器は、証明のすべてのクライアントの公共入力をMerkleツリーに登録し、ツリーの根を集約証明の公共証人として公開します。
- 集約器はオンチェーンで集約証明を提出し、スマートコントラクトはその証明を検証し、約250,000ガスのMerkleツリーの根を記録します。（これはETHから特定のERC-20トークンへのUniswap呼び出しの価格に相当します）。現在、1つの証明には32〜64のユーザー証明が含まれ、検証のガス料金はこれらのユーザーで分担されるため、各ユーザーがZKP検証に支払うガス料金は、ほぼ1回のオンチェーンETH送金に相当します。
- ユーザーは「claim」呼び出しを提出し、Merkle証明を行い、ハッシュメッセージを使用して自分のアイデンティティを識別し、証明されたZKPのリンクを自分のアドレスに結びつけます。
オンチェーンアドレスとユーザーが提出したアイデンティティハッシュを除いて、集約器、スマートコントラクト、私たちはユーザーのアイデンティティについて何も知りません。
どのように実現し、どのように改善するか
この部分は少し技術的で、ZKPの背景知識が必要です。
- クライアントでは、Plonky2を使用することを選択しました。これはFRI+Plonkを使用したGoldilockのZKPシステムです。信頼できる設定を必要とせず、迅速な証明時間と合理的なメモリ消費を提供します。私たちは、アイデンティティを検証するための最低限の要件を満たすように回路を簡素化し、コンパイルされたWASMバイナリは約3MBです。
- 集約器側では、まずPlonky2証明を「ラップされた」Plonky2証明に集約します。この証明は、大量のPlonky2証明を1つに集約し、正しい回路構造を検証します（つまり、ユーザーが私たちの期待通りに正確な回路を実行し、公共証人をMerkleツリーに圧縮してスペースを節約するなど）。
- Plonky2が集約された後、Gnark内部でPlonky2検証器を実行し、証明と検証器キーをオンチェーンで迅速に検証可能な形式に変換します。Gnarkの集約は主な時間消費者であり、約2分半かかります。
- 最後に、集約証明を通じて、ユーザーは一般的なPlonky2+Gnark検証器コントラクトを使用して、低コストで自分を検証できます。必要なガスは211,000で、オンチェーン呼び出しのストレージオーバーヘッドを加え、検証コストは250,000ガス以下に抑えられます。
現在、OpenID3のZKP部門では2つの作業が進行中です：
- GPU加速などの魔法を使ってGnarkの集約時間を短縮し、目標は30秒未満です；
- ツリー依存性を揺さぶり、実行ファイルのサイズをさらに最小化し、できれば1MB未満にすることを目指しています。
最後に
クライアントZKPは探求者が少ない分野であり、私たちは他のチームと協力して私たちが採用したプロセスを標準化したいと考えています。
- フレームワークやDSLは、簡単に構成できるPlonky2回路を中心に構築できます。
- 私たちはまだ多くのプロセスに折りたたみ最適化を導入しておらず、集約折りたたみを通じて大幅な性能向上を期待しています。
- 集約器サービスや一般的なオンチェーン検証サービスを構築でき、ZKPの未来の重要なインフラとして、より大きなコミュニティに安全性、分散化、優れた開発者体験を提供します。
