ゼロ知識証明を使用してイーサリアム上でプライバシーアプリを構築する方法

ゼロ知識証明

プライバシー

フィリップ・クラウス

EF Builder Growth

2026年5月12日

14 分で読めます

イーサリアムは設計上、徹底的に公開されています。すべてのアドレス、残高、トランザクション、コントラクト呼び出し、およびイベントは、ブロック・エクスプローラーを使用すれば誰でも見ることができます。この透明性は、検証可能性を求める場合には有用です。しかし、ユーザーがすべてのアクションを同じウォレットに結びつけることなく、投票、請求、引き出し、またはメンバーシップの証明を行う必要がある場合には問題となります。

匿名メンバーシップは、イーサリアム上の大規模なプライバシーアプリを機能させる再利用可能なパターンです。人々は最初に登録を行い、後で自分がどのメンバーであるかを明かすことなく、グループに属していることを証明します。ゼロ知識証明は、登録ウォレットと実行ウォレットの間のブリッジであり、このブリッジは誰がそこを渡ったかを明かしません。

周囲のプロダクトが変わっても、プライバシーの骨格は同じままです。

匿名投票を通じて説明するパターン

このパターンには3つの要素があります。コミットメントは各メンバーを登録します。マークル・ツリーはそれらのコミットメントを群衆に変えます。証明とヌリファイアにより、1人のメンバーが、どのメンバーが行動したかを明かすことなく1回だけ行動できるようになります。

ステップ1：登録

すべての投票者は、オフチェーンでシークレットとヌリファイアという2つのプライベートな値を作成します。投票者はこれらの値をハッシュして公開コミットメントにし、そのコミットメントをオンチェーンに登録します。

コミットメントは公開された登録記録です。シークレットとヌリファイアは、投票者が後で必要とするプライベートなメモです。このメモを紛失すると、投票者はメンバーシップを証明できなくなります。漏洩すると、他の誰かがユーザーの代わりに投票できるようになる可能性があります。

コミットメントはハッシュであるため、観察者はその中のプライベートな値を復元することはできません。コミットメントは、後で誰がその登録を使用するかを明かすことなく、「誰かが登録した」ことだけを示します。

ステップ2：群衆の構築

より多くの投票者が登録するにつれて、アプリは彼らのコミットメントをマークル・ツリーに収集します。マークル・ツリーは、値の長いリストをルートと呼ばれる単一のハッシュに圧縮します。リスト内のいずれかの値を変更するとハッシュも変わるため、ルートはセット全体の改ざんが明らかな要約として機能します。

そのツリーが匿名性セットになります。ツリーに10人のユーザーがいる場合、観察者は後のアクションをその10人のうちの1人に絞り込むことができます。ツリーに1万人のユーザーがいる場合、アクションを1人の人物に結びつけることははるかに困難になります。匿名性セットが非常に小さいプライベートアプリは、暗号技術が正しくても、通常はあまりプライベートではありません。

ステップ3：匿名での行動

投票が開始されたとき、投票者はコミットメントを登録したのと同じウォレットから投票するべきではありません。登録ウォレットから投票すると、投票が登録者に直接結びつき、プライバシーの取り組みが台無しになります。代わりに、投票者はゼロ知識証明を作成します。このステートメントは、「私は登録されたコミットメントを生成するプライベートな値を知っており、この投票のための正しいヌリファイアのハッシュを公開します」という回路としてエンコードされます。

この証明は、ステートメントが真であることを検証者コントラクトに納得させます。シークレット、ヌリファイア、またはどのコミットメントが使用されたかを明かすことはありません。

ヌリファイアは二重投票を防ぐためのものです。証明とともに、投票者はヌリファイアのハッシュを公開します。投票コントラクトは、投票を受け入れた後にそのハッシュを保存します。同じ投票に対して同じプライベートなメモが再び使用された場合、同じヌリファイアのハッシュが生成され、コントラクトは2回目の投票を拒否します。証明と組み合わせることで、コントラクトは「登録された投票者の誰かが1回行動した」ことだけを知り、それが誰であるかはわかりません。

再利用可能なゲート

その同じ証明とヌリファイアのペアは、投票以外でも機能します。投票という文脈を取り除くと、スマート・コントラクト関数のためのプライバシーゲートが残ります。

関数が実行される前に、コントラクトはマークル・ルートをチェックし、証明を検証し、ヌリファイアのハッシュが使用されていないことを確認し、公開入力を適切なアプリ、チェーン、投票、請求、または引き出しにバインドします。これらのチェックに合格すると、ヌリファイアを使用済みとしてマークし、関数の残りの部分を実行します。

そのゲートを投票の前に置けば匿名投票になります。エアドロップの請求の前に置けば匿名での請求になります。引き出し関数の前に置けば、ミキサースタイルの引き出しフローのコアになります。同じコミットメントのツリー、同じヌリファイアのアイデア、同じ証明パターンです。変わるのは関数の本体と周囲のアプリのロジックです。

何がどこで実行されるか

プライベートな作業は通常、オフチェーンで行われます。ユーザーはメモを保存し、クライアントアプリはウィットネスを構築し、プルーバーを実行して証明を生成します。インデクサーはコミットメントとマークル・ルートを追跡します。バンドラーはユーザーオペレーションをオンチェーンに伝播させ、ERC-4337のペイマスターがガスをスポンサーするため、新しいウォレットは最初にユーザーの既知のウォレットからETHを受け取る必要がありません。

公開された強制執行はオンチェーンで行われます。検証者コントラクトは証明をチェックします。アプリのコントラクトは、有効なルートと未使用のヌリファイアをチェックし、ヌリファイアのハッシュを保存して、公開アクションを実行します。

機密性の高いUXはメモの取り扱いです。シークレットとヌリファイアは鍵のように扱ってください。これらを分析、ログ、URL、エラーレポート、または通常のサーバー側のテレメトリに入れないでください。メモが漏洩すると、証明がどれほど強力であってもプライバシーは失われます。

追いついてきたツール

基盤となる暗号技術を手作業でコーディングする必要はありません。一般的な方法は、高レベルのゼロ知識言語で回路を記述し、Solidityの検証者を生成して、アプリのコントラクトからその検証者を呼び出すことです。

適切なスタックはタスクによって異なります。snarkjsを使用したCircomは、アプリレベルの回路として古くから確立された方法です。Barretenbergを使用したNoirは、より新しく開発者フレンドリーな方法です。Halo2とgnarkは、より低レベルの回路ライブラリです。RISC ZeroやSP1などのzkVMは通常のプログラムを証明しますが、小規模なカスタム回路よりも証明のコストが高くなる可能性があります。

匿名メンバーシップについては、独自の回路を書く前に既存のプロトコルを利用してください。Semaphoreは、グループメンバーシップとヌリファイアベースの二重使用防止機能をコントラクトとJavaScriptライブラリにパッケージ化しています。プライベートな投票やガバナンスについては、共謀防止の特性を追加するMACIが専門的な方法です。成熟したプロトコルは、新しい回路よりも安全であることがよくあります。

証明だけでは不十分

ウォレットのフローでリンクが漏洩した場合、完璧な証明であっても失敗します。ウォレットAから登録し、後でウォレットAから行動すると、監視している誰もがトランザクションを結びつけることができます。行動の直前にウォレットAからウォレットBに資金を供給すると、その資金供給トランザクションが同じ問題を引き起こします。

これが、バンドラーとペイマスターが重要である理由です。行動するウォレットは新しいものであるべきであり、ユーザーがアクションから切り離そうとしているウォレットからETHを受け取る必要がないようにすべきです。

同じ問題はオフチェーンにも存在します。同じIPアドレス、RPCプロバイダー、またはセッションから登録とアクションのトランザクションを送信すると、回路が提供するプライバシーが弱まる可能性があります。フロントエンドは、分析、ローカルストレージ、およびサポートログを通じて漏洩する可能性があります。ゼロ知識証明は、証明の内部にある値を隠します。トランザクションの周囲のすべてを隠すわけではありません。

公開入力も、プライバシーアプリが失敗するもう一つの要因です。回路内で公開とマークされたもの、イベントとして発行されたもの、コールデータに含まれたもの、またはコントラクトによって保存されたものはすべて可視化されます。Solidityコントラクトのアクセス制御と同じくらい慎重に公開入力をレビューしてください。

これがビルダーにどのような変化をもたらすか

イーサリアム上のプライバシーは実現可能です。ビルダーはこれらの要素を組み合わせて実際のアプリケーションを構築できます。スタックは、プライベートなステートメントのための回路、証明チェックのための検証者、公開ルールのためのアプリのコントラクト、マークルデータのためのインデクサー、そしてリンク不可能な送信とガスのスポンサーシップのためのバンドラーとペイマスターで構成されます。

難しい部分は、プロダクト設計、鍵管理、メタデータの衛生管理、監査、そして匿名性セットの拡大です。これらのいずれかを間違えると、証明が提供したプライバシーは失われます。

参考文献

ページの最終更新: 2026年5月28日