見出し画像

ゼロ知識証明のその先 【前編】

本郷web3バレー

はじめに

こんにちは！本郷Web3バレーです。
Stanford Blockchain Reviewシリーズになります。
このシリーズではStanford Blockchain clubの業界レポートであるStanford Blockchain Reviewを日本語に翻訳したものを要約と我々の観点とともに発信していくものとなっています。
翻訳の許可をくださったStanford Blockchain ReviewのJayYuには感謝申し上げます。
前編では本文とその要約を、後編では我々の議論内容と観点を発信します。前編を追いながら後編を見ていただけるとわかりやすいのかなと思います。
今回扱うテーマは「ゼロ知識証明(ZKPs)の限界とその他のセキュリティスキーム」です。
本記事では、ゼロ知識証明が持つ性質によってブロックチェーン上にて応用が注目されている現状に対して、実際にはゼロ知識証明には限界があり、その他のソリューションを提示し、セキュリティ担保のためには複数の手段を総合的に検討する必要がある、という見解を示します。

概要

ゼロ知識証明（ZKPs）はプライバシーを保ったまま証明対象の処理コストを減らすことができるが、グローバルレベルでは秘密の保持が難しい。FHEは暗号データのまま（生データを見ずに）計算を可能にするが現状効率が悪い。MPCは複数ユーザの関係を前提としている、元々ブロックチェーンに馴染む構造で、閾値FHEと組み合わせることもできる。TEEはサーバーに信頼できる実行環境を強制するハードに依存するアプローチであり、プライバシーを保ちながら正確な計算が可能である。これらのプライバシーツールを組み合わせて活用することが重要であり、プライバシーテクノロジーを適切に利用するためにはそれぞれの長所と制約を理解する必要がある。多様なプライバシーツールに柔軟に対応することがオンチェーンプライバシーの普及につながる。

要約

ゼロ知識証明は万能薬ではない。
ゼロ知識証明はプライバシーを保ったまま証明事項をまとめて処理コストを落とすことができる。これは一対一の取引上ではうまくいくが、「グローバル」レベル（ネットワークレベル、アプリケーション、多者間）での秘密の保持はできない。
証明できるのは元情報を自分が知りうるからで、他人の情報を知らないままに、その情報をその証明に組み込むことはできないからだ。
プライバシーを保つ社会行動を可能にする技術として注目するものをいくつか提示する。
FHE：復号化せずとも、中の状態を知らないままに計算が可能となる技術。しかしながら、現状そのプロセスは非効率で複数の異なる鍵で暗号化されたデータを統合して計算することができない。 それゆえ、部分的な同型暗号化スキームPHEで特定の計算に限って暗号化する技術があるが、一般的な応用は難しいとされる。
MPC：分散システムのアプローチで個人データを処理するシステムで、構造からしてブロックチェーンアーキテクチャに適応する。複数のユーザの関係を前提とするので、FHEにあった弱点を補う。FHEと共に「閾値FHE」を作成することもできる。 MPCには鍵がなく、暗号化されたデータを分割所有し、復号化のためにその全データが必要になるために、サーバーが暗号化鍵にアクセスするリスクがそもそもない。それには閾値が設定できて、DoS攻撃への対応のためにその必要とする鍵のシェアを調節できる。 当事者が共謀した攻撃によるプライバシー侵害は検証不可能で、サーバーが外部で鍵を共有するとデータ復号化が秘密裏に達成されてしまう。多くのサーバーで計算することで共謀攻撃を防ぐが、生存性の観点からMPCはスケールが難しく、他の対策が必要。
TEE：MPCの共謀を防ぐ別の手段として、サーバーに信頼性のある実行環境(TEE)を使用することを強制する方法がある。また、Partisia Blockchainのように、部分的に信頼されたノード群がプライベート計算を行い、ブロックチェーンで状態を保存・検証する方式も共謀を困難にする。 別のプライバシー保持手段、TEEは、計算をCPUから切り離した「ブラックボックス」で行うことで、データを安全に保管する。これを利用すれば、サーバー上でプライバシーを維持しながら正確な計算が可能となる。 TEEは純粋な暗号技術に頼るのではなく、ハードウェアに依存するので、効率が良いが、サイドチャネル攻撃のリスクがつきまとう。それでも、TEEは低感度のデータに対して高性能な計算を行う上で現状は最適な選択肢であり、セキュリティの強化とスケーラビリティの向上を図りつつ、共謀を防止する効果がある。
開発者は、ゼロ知識証明（ZKPs）と多者間計算（MPC）を組み合わせることにより、プライベートなアプリケーションを構築することが可能である。また、Trusted Execution Environments（TEE）というハードウェアベースの解決策も存在している。MPCは暗号化されたデータに対する計算を可能にし、ZKPsはユーザーの認証やトランザクションの検証といった分野で有用である。
議論を通じて明らかとなったように、各プライバシーソリューションには利点と欠点がある。全てのプライバシー要求を満たし、リスクがゼロの単一のソリューションは存在しない。プライバシーテクノロジーを適切に利用するためには、その制約を理解する必要がある。これを理解した上で、ZKPs、TEE、MPC、FHEなどのプライバシーツールを組み合わせて活用するべきである。オンチェーンプライバシーを普及させるには、多様なプライバシーツールに対して柔軟である必要がある。

本文

導入

ゼロ知識証明（ZKPs）の可能性は、一部の人々を魅了しています。このような人々にとって、ZKPsは暗号技術の楽園のように感じられ、ZKPsで解決できない問題はないと信じられています。
ZKPsは、一部の人々によって包括的なプライバシー解決策という印象が付いていますが、これは単純に不正確です。この記事の目的は、ZKPsができることとできないこと - 特にプライバシーに関して - について正直な評価を提供することです。また、ZKPsを強化するためにZKと併用できる補完的なツールについても検討します。
ZKPsには素晴らしい強みがある一方で、限界もあります。それらの全能感の錯覚から抜け出すためには、両方を理解することが不可欠です。その理解をもって初めて、建設的にプロジェクトに組み込むことができます。
ZKPsは、詳細を明かさずに知識を証明することをユーザーに許可する ゼロ知識証明は、ユーザーが何かを知っていることを証明することができる一方で、それについての詳細を明かさないようにします。これを実現するためには、「証明者/テスター」と「検証者」が必要です。
ZKPsを説明するのに役立つ有名な話があります：
二人の友達、アリスとホルヘが洞窟を見つけます。この洞窟には中央にある扉に繋がる二つの入り口・出口があります。この扉には、二つの道を繋げるとされる暗証番号があるとされています。
ホルヘは扉の暗証番号を知っていると言います。アリスは彼から暗証番号を買いたいと思っていますが、彼が本当にそれを知っていることを確認したいと考えています。ホルヘはただちに暗証番号を教えることはできません。そこで、二人は“ゼロ知識”の交換テストをすることにします。
アリスはホルヘに洞窟のどちらかの道から入るように指示します。もし彼が本当に暗証番号を知っているなら、彼は他の道から出ることができるはずです。
ゼロ知識証明は、この話に対する暗号技術を用いた形の解決策です。それらは特別な手順を踏んで「証明」を生成し、両当事者間で実質的な知識の交換が必要ないようにします。

ZKPsは取引のプライバシーとスケーラビリティを提供する

ZKPsの簡単な使用例として、ユーザーの特定や署名の確認が挙げられます。これにはZKPsの強みが活かされています。
ZCashのようなプロジェクトでは、ゼロ知識を活用して取引のプライバシーを確保しています。
ZKPsは、スケーラビリティを与えることでよく知られています。情報のパケットは軽量な「証明」に置き換えることができ、これによりブロックチェーンの混雑が緩和され、取引が速くなります。これにより、ZKPsは高度にスケーラブルなレイヤー1、またはゼロ知識ロールアップのようなレイヤー2のスケーリングソリューションを構築するのに適しています。

ZKPsは安全な計算や、安全な拡大に対応できない

ZKPsは「ローカル」レベル（取引レベル）でのプライバシーを実現することができますが、「グローバル」レベル（ネットワークレベル、アプリケーション、多者間）での秘密の保持はできません。
例えば、DeFiをプライベートにするためには、ユーザーがスマートコントラクトに基づくDEXのような信頼性のないエージェントと取引しながら、データを常時プライベートに保つ必要があります。しかし、これはZKPsでは実現できません。
ZKPsのプライバシーは、取引から安全な計算の領域に移ると崩壊します。
Secret LabsのCEOであるGuy Zyskindは、これが実際にどのように機能するかを説明しています：

中央集権的なセクター（通常、シーケンサと呼ばれる）が、オフチェーンで全ての取引（および計算）を実行します。これは、クライアントがブロックチェーンではなく、このシーケンサと直接やりとりし、暗号化されていない入力データを送信することを意味します。シーケンサは全ての計算を実行した後、簡潔な証明を生成し、出力（通常は更新された状態）と共にブロックチェーンに送信します。ブロックチェーンは検証者として機能し、証明が正しいことを確認し、そうであれば、クライアントのデータを直接知ることなく、状態の変更を適用します。全ての汎用的なブロックチェーンZKソリューションは、このスケーリング方法を使用しています。

これは単純です。あなたが自分のデータを見ることができれば、それを証明できます。しかしそれでは他の人のデータとの類似性や違いを証明することはできません。それを行うのは誰か、または何か？シーケンサは、全参加者のデータに対して証明を生成します。
しかし、ユーザーがオフチェーンの中央集権的なシーケンサを信頼する必要がある場合…私たちはWeb2の基本的な問題に戻ってしまいます。

また、インフラストラクチャ層での情報漏洩に関する理論的な懸念もあります。たとえば、ZKPsは取引サイズの分析や、ZKPs取引に関する情報を漏らす可能性のあるような形式のメタデータに対しては保護しません。
まとめると、ZKPsはローカルレベルで秘密を保つのには優れています（ピアツーピア取引など）。しかし、同じデータをグローバル/ネットワーク規模でプライベートに保つことはできません。
これは、大きくは、ゼロ知識証明がスマートコントラクトやDEXをプライベートにすることができないためです。そして、残念ながら、ZKPsがプライバシーに対して万能であるわけではありません。

ZKPsの強みと限界は、他のプライバシー解決策と比べてどうか？

暗号技術においては、「最適な」方法はめったに存在しません。ここで挙げられる各解決策には複数の構成要素があり、単独または他の解決策と組み合わせて、ケースごとに興味深い問題を解決するために使用することができます。下のグラフィックで示されているように、それぞれの構成および組み合わせは、トレードオフと相対的な利点が伴います。

完全同型暗号化は、復号化することなく暗号化されたデータ上で計算を行う

完全同型暗号化（Fully homomorphic encryption,FHE）は理解しやすい考えですが、実装するのは非常に難しいです。
プライバシーを保護しない1台のサーバーと1人のユーザーだけが存在する世界を想像してみてください。この状況でプライバシーをどのように守るのでしょうか？
FHEを使用すると、ユーザーは暗号化されたデータをサーバーに送信し、サーバーはそのデータを生の形式で見ることなく計算することができます。

FHEは、既存のプライバシー技術の中で最も非効率的

残念ながら、これまでのところ、FHEは非常に非効率的であり、実際には、私たちが知っているプライバシーを保護する技術の中で最も遅いものです。しかし、FHEの計算効率は驚異的な速さで向上しており、特化したハードウェア（CPU → GPU → FPGA → ASIC）によって、今後10年で計算速度がさらに数桁向上するでしょう。
しかし、5〜10年後であっても、FHEの機能を使用することは、特定のユースケースやスマートコントラクトの実行の一部に対してしか機能しない可能性が高いです。たとえば、暗号鍵や社会保障番号のような非常にセンシティブな（かつ小さな）データを保存して操作するためにFHEを使用するかもしれません。

FHEは、異なる鍵で暗号化されたデータを計算することができない

この安全性が担保された計算の問題に2番目のクライアントをどのように導入するのでしょうか？
世界には2人のクライアントしかいないと想像してみてください。両方のクライアントにはそれぞれの入力があり、その入力に対して関数を計算したいと考えています。両方ともプライバシーを求めています。
「純粋な」FHEでは、各クライアントが自分の鍵を使用してデータを暗号化しているため、これをどのように行うかは不明です。
FHEは、異なる鍵で暗号化されたデータ上で計算することができません。では、これをどのように解決するのでしょうか？

部分同型暗号化（PHE）は一般的なスマートコントラクトをサポートできません

この問題を解決するためには多くの方法が必要であることがわかります。暗号化されたデータに対して任意の関数を計算できる完全同型暗号化に加えて、部分的な同型暗号化スキーム（HEまたはPHE）も多く存在します。これらの部分的なスキームは特定の機能性（通常は加算または乗算のいずれか）を計算することができますが、両方はできません（すべての関数が加算と乗算の操作に還元されることに注意）。これらの部分的なHEスキームは数十年前に発明され、はるかに効率的で、限定されたユースケースには十分かもしれませんが、セキュアな計算の一般的なケースには十分ではありません。
いくつかのネットワークは、PHEのような部分的なスキームを使用してプライバシーを実現しようとしています（例：PenumbraやDero）。ただし、それらが定義上、汎用のスマートコントラクトをサポートすることはできないと理解することが重要です。これらの技術のプライバシーに焦点を当てたブロックチェーンへの応用は斬新ですが、サポートできるユースケースはかなり限定的です。
このような部分的な解決策でサポートできるアプリケーションの範囲を拡張する非自明な方法が存在しますが、これには暗号技術における深い専門知識が必要です。これらのアプリケーションは、理解するのが難しい他の隠れたトレードオフをしばしばもたらします。そのため、PHEは開発者がプライバシーを保った任意のアプリケーションを構築することを許可することはおそらくありません。
したがって、FHEまたは部分的なHEソリューションだけでは、複数のクライアントのセキュアな計算の問題を解決できない場合... 何ができるのでしょうか？

セキュアな多者間計算（MPC）は、システム全体に計算を分散させます

MPCは、プライベートデータに対する計算を分散システムのアプローチで行うものです。その意味で、ブロックチェーンの基本的なアーキテクチャに自然に適合しています。
MPCでは、単一のサーバーを信頼する代わりに、複数の信頼されていないサーバーがクライアントデータ上で計算を共同で実行します。信頼の前提を変更することで、適応範囲が大幅に拡大します。MPCのソリューションは、複数のクライアントを想定して開発されています。したがって、サーバーが複数のユーザーからのデータを組み合わせることには理論的な問題はありません（FHEとは異なります）。
興味深いことに、MPCはFHEと組み合わせて「閾値FHE」を作成することができます。しきい値FHEは、単一のFHE暗号化キーをすべてのサーバー間で分割します。

MPCは非共有によるセキュリティに依存しています

FHE（のみ）を使用すると、ユーザーは秘密の暗号化鍵を保持し、サーバーが彼女のデータにアクセスすることはしません。
しかし、MPCの場合、すべてのサーバーが共謀すれば、プライベートデータを再構築できます。1つのサーバーが正直である限り、この共謀は回避され、モデルは安全です。
この時点で重要なのは、MPCのソリューションには鍵が含まれていないということです。代わりに、MPCはデータを隠すために、各サーバーにデータの「暗号化された」シェアを与え、データを「復号化」するためにすべてのシェアが必要となります。さらに、各シェアだけでは、平文データについて何も明らかにしません。

実際には、生存性(liveness)またはプライバシーを最適化するために、共謀のしきい値をカスタマイズすることができます。上記の例では、すべての共有された鍵がデータを再構築するために必要となり、最大限のプライバシーを得ることができます。
ただし、システム全体に対してサービス拒否攻撃（DoS攻撃）を仕掛けるためには、1つのサーバーで十分です。これは、クライアントのリクエストに対して1つのサーバーが応答しないだけで、結果が計算されないためです。
一方で、キーシェアの1/2または2/3だけが必要とすることができます。これは、サーバーの過半数が正直であり、計算の実行中に共謀しないことが必要です。

MPCでは、正確性の担保よりもプライバシー問題解決の方が難しい

MPCにおいて正確性は検証可能です。取引が改ざんされた場合、それは検出されるか、あるいは合意が停止します。しかし、プライバシーに対する共謀攻撃は検証できないため、これは「ステルス」の攻撃となります。
サーバーが（システムの外部で）鍵を共有して共謀した場合、データを復号化できることを我々は知ることはありません。この攻撃経路を排除するために、共謀攻撃を回避しながら、可能な限り多くのサーバーで計算を実行するようにすることができます。
残念ながら、MPCは参加者の数が増えるにつれてスケールしにくくなり、サーバーの数を増やすと生存性(liveness)が損なわれます。したがって、MPCだけでは不十分であり、共謀を困難にする他の技術を実装する必要があるようです。

TEEはMPCの共謀攻撃経路を複雑にする

MPCの共謀をより困難にする方法の1つは、分散システム内のすべてのサーバーに信頼性のある実行環境（Trusted Execution Environments、以下TEE）を使用するよう強制することです（これについては以下で詳しく述べます）。
あるいは、許可された環境で動作することで共謀を複雑にすることができます。ここでは、サーバーが（部分的に）信頼されており、データ漏洩が発生した場合に再識別することができます。これはPartisia Blockchainが進めている方向のようです：オフチェーンの半信頼ノード群がプライベートな計算を実行し、ブロックチェーンは状態のみを保存して検証します。

Trusted Execution Environment（TEE）は、コンピュータのCPUから計算を分離して行うテクノロジー

TEEは、処理を「ブラックボックス」に移動させることで、コンピュータのCPUからはアクセスできなくします。この領域（ブラックボックス）はデータ（暗号化キーなど）を保管し、マシンのホストが改ざんできない計算を実行できます。また、ホストはその領域に保存されているデータを抽出することはできません（少なくとも理論上は）。
TEEを使用すると、プライバシーと正確性を確保しながら、サーバー（またはブロックチェーンの設定によっては複数のサーバー）で全ての計算をTEE内で実行するように要求できます。さらに、クライアントに、サーバーのTEE内でのみ利用可能な鍵を使用して入力データを暗号化するように求めることができます。
この設計では、サーバーを所有するホストでさえも、クライアントのデータにアクセスすることはできません。これは、データがTEE内でのみ復号化され、計算されるためです。このようなシステムが実際にどのように機能し、暗号化キーがどのように保護されているかについての詳細は、Secret Networkの技術文書を参照してください。
TEEを考えるもう一つの方法は、先に想像したシンプルな世界（単一のユーザーと計算を正確かつプライベートに実行できる単一の信頼されたサーバー）のハードウェア近似として捉えることです。ただし、TEEを最大限に活用することは、その世界よりもはるかに複雑です。検閲やDoS攻撃を防止するためには、単一のサーバーに依存するのではなく、TEEをブロックチェーンのような分散システムで使用するのが最良です。
TEEシステムは、純粋な暗号技術に頼るのではなく、ハードウェア依存でセキュリティを確保するため、非常に効率的です。暗号技術によるソリューションは、一般的にクリアな計算よりも桁違いに遅いですが、TEEはほとんどの場合、計算時間に40％未満のオーバーヘッドしかかかりません（追加で必要なリソースが40％未満である）。この分は主に、入力を復号化し、プライバシーを保護するために出力を再暗号化する時のコストです。

TEEに対する主な懸念点は、サイドチャネル攻撃の可能性です。近年、研究者たちは、TEEから情報を抽出する方法を示しており、これは主に現代のプロセッサーが効率を得るために使用するスペキュレーティブ実行を使用しています。これらの問題のほとんどはソフトウェアやハードウェアで解決でき、実際に悪用するのは難しいですが、この特定の攻撃ベクトルでは純粋な暗号技術と比較して不利です。アーキテクチャ上のバグ（セキュアなエンクレーブだけでなく、あらゆる種類のハードウェアに影響する可能性があります）も可能であり、真剣に検討すべきリスクです。
これらのトレードオフを考慮しても、TEEは特に低感度データに対する高性能計算のための最良の実用的な解決策として現在も位置づけられています。解決策の中核が暗号的な性質である場合でも、TEEはセキュリティを強化する上で重要であり、スケーラビリティを向上させながら共謀を防止するのに役立ちます。

Zero-Knowledge Proofs（ZKPs）は、ブロックチェーンプライバシーソリューションと組み合わせることで「強化」される

例えば、開発者はZKPsを多者間計算（MPC）と組み合わせて、完全にプライベートなアプリケーションを構築することができます。また、ハードウェアベースのソリューション（Trusted Execution Environments、TEE）もありますが、TEEを使用する場合、追加のZKPsはおそらく不要です。
多者間計算は、暗号化されたデータ、つまりプライベートなデータに対する計算を可能にすることで、ZKPsの欠点を補います。したがって、スマートコントラクトレベルでデータをプライベートに保つことができます。
この例では、DEXの内部状態が暗号化されており、MPCによってデータを復号化することなく、データの上で計算を実行し更新することができます。これにより、データは常にプライベートに保たれます。
最終的に、ZKPsはユーザーの特定、署名、軽量トランザクションを検証する分野で強みを発揮します。

Web3のプライバシーの未来は万能ではない

この議論を通じて見てきたように、各プライバシーソリューションにはそのトレードオフがあります。そして、どんなにうわさされていることがあっても、私たちのプライバシーのニーズをすべて満たし、リスクがゼロの単一のソリューションは存在しません。
プライバシーテクノロジーを使って責任を持って構築するには、その固有の制限を理解する必要があります。
これらが明確に理解されたとき、私たちはより広範なプライバシーツールボックスにアクセスし、その技術をそれぞれの弱点を補完するソリューションとペアにする可能性があります。ZKPs、TEE、MPC、およびFHEは、それぞれの強みと制約を持って何かを提供します。
オンチェーンプライバシーはユーザーにとって「通常」であるべきです。そのビジョンに向けて構築するには、単一のソリューションに固執するのではなく、さまざまなプライバシーツールに対応して開かれている必要があります。

著者紹介

Secretは、ビルダーとユーザー向けのプライバシーソリューション群を構築しています(Secret 2.0)。私たちのビジョンは、誰もがプログラム可能なプライバシーを持つ汎用性と組み合わせ可能な分散アプリケーションを構築できるようにすることです。
SeanはSecret Agency DAOの共同創設者であり、ネットワークの教育コンテンツクリエーターです。Guy ZyskindはSecretの創設者であり、Secret LabsのCEOで、2020年にSecretのメインネットに世界初のプライベートスマートコントラクトをもたらしました。元MITの研究者として、彼は最も引用されたブロックチェーンプライバシー論文の一部（2015年に書かれた“Decentralizing Privacy”など）の著者です。
Secret Universityで無料のオンラインRustトレーニングへの参加はこちら：https://scrt.university HackSecretのビデオやリソースはこちら：https://scrt.network/hacksecret-2023

翻訳元の文献

[1] https://scrt.network/blog/beyond-zk-guide-to-web3-privacy-part-1/
[2] https://scrt.network/blog/beyond-zk-guide-to-web3-privacy-part-2
[3] https://homepage.cs.uiowa.edu/~ghosh/blockchain.pdf
[4] What Zero Knowledge Proofs (ZKPs) Can and Can't Do
[5] Guy Zyskind Speaks on Beyond ZK at the UPA Summit
[6] Web3 Privacy Panel at Secret Network's Secret Summit

*この文章はchatgptで翻訳したものを修正したものになります

この記事が気に入ったらサポートをしてみませんか？