Author: EQ Labs Source: equilibrium Translated by: Good Oba, Golden Finance
プライバシーシリーズのパート1では、プライバシーの意味、ブロックチェーンネットワークにおけるプライバシーがweb2のプライバシーとどう違うのか、ブロックチェーンでプライバシーを実現するのが難しい理由を紹介した。"、ブロックチェーンネットワークにおけるプライバシーは何を意味し、どのようにウェブ2のプライバシーと異なるのか、そしてなぜブロックチェーンでプライバシーを実現するのは難しいのか。
この記事の要点は、もし理想的な最終状態が、単一障害点なしに共有されたプライベート状態を扱うことができるプログラマブルなプライバシーインフラを持つことであるならば、すべての道はMPCにつながるということです。そして業界の概要を提供します。
過去からの脱却と未来の受け入れ
ブロックチェーンにおける既存のプライバシー基盤は、私的な支払いや投票など、非常に特定のユースケースを扱うように設計されています。これは、ブロックチェーンの現在の用途(取引、送金、投機)を大きく反映した、かなり狭い見方です。トム・ウォルポが言うように、暗号通貨はフェルミのパラドックスに苦しんでいるのだ。https://images.ctfassets.net/mcxwnmool9vd/3hV84perhjluFt2m2srmcC/4c3ba54fb02e00b1df77d7de492a6d10/image.png?f=center&fit=fill&w=640&h=454&q=75 1x, https://img.jinse.cn/7280554_watermarknone.png 2x" src="https://img.jinse.cn/7280554_watermarknone.png">
個人の自由を高めることに加えて、私たちは、プライバシーが、現在の投機的なメタデータを超えてブロックチェーンのデザイン空間を拡大するための前提条件であると考えています。
非表示の状態: 金融ユースケースの大部分は、(少なくとも)非表示にする必要があります。また、多くのマルチプレイヤーゲームは、隠された状態(例えば、ポーカーテーブルの全員がお互いのカードを見ることができる状態)がないと、あまり面白くありません。
隠しロジック: 使用例によっては、マッチングエンジン、オンチェーン取引戦略など、他のユーザーがアプリを使用できるようにしながらも、いくつかのロジックを隠す必要があります。
(Web2 および Web3 からの)経験的な分析によると、ほとんどのユーザーは、プライバシーを追加するために追加料金を支払ったり、追加セッションをスキップしたりすることを望んでいません。しかし、ブロックチェーンの上に新たな、そして(願わくば)より有意義なユースケースを存在させることができます。
プライバシー拡張技術(PET)と最新の暗号ソリューション(「プログラマブル暗号」)は、このビジョンを実現するための基本的な構成要素です(利用可能なさまざまなソリューションとそのトレードオフの詳細については、付録を参照してください)。
私たちの見解に影響を与える3つの仮定
3つの重要な仮定が、ブロックチェーンのプライバシー基盤がどのように進化するかについての私たちの見解を決定します:
暗号はアプリケーション開発者から抽象化される:ほとんどのアプリケーション開発者は、プライバシーを処理するために必要な暗号を使いたがらない(または何をすればいいかわからない)。アプリケーション開発者が独自の暗号を実装し、アプリ固有のプライベートチェーン(例:ZcashやNamada)を構築したり、パブリックチェーン(例:Tornado Cash)の上にプライベートアプリを構築したりすることを期待するのは不合理です。これは単純に複雑すぎ、オーバーヘッドが多すぎ、現在ほとんどの開発者のデザイン空間を制限しています(特定のプライバシー保証を必要とするアプリケーションを構築することができません)。したがって、暗号化コンポーネントを管理する複雑さは、アプリケーション開発者から抽象化されなければならないと考えています。ここでの 2 つのアプローチは、プログラム可能なプライバシー インフラストラクチャ (共有プライベート L1/L2) または、秘密計算のアウトソーシングを可能にする 「secrets-as-a-service」 です。
多くのユースケース (おそらく私たちが考えているよりも多い) は共有プライベート状態を必要とします。共有プライベート・ステートはこのサブセットで、複数のパーティが同じプライベート・ステート上で計算を行う。中央集権的なパーティを信頼して、これをやってもらって終わりにすることもできるが、理想的には、単一障害点を避けるために、信頼を最小化する方法でこれを行いたい。ゼロ知識証明(ZKP)だけではこれを達成することはできません。信頼された実行環境(TEE)、完全同型暗号化(FHE)、マルチパーティコンピューティング(MPC)など、他のツールを活用する必要があります。
より大きなマスキングセットでプライバシーを最大化する:ほとんどの情報は、マスキングセットに出入りするときに危険にさらされるため、これを最小限に抑える必要があります。同じブロックチェーン上に複数のプライベートアプリを構築することで、同じマスキングセット内のユーザーとトランザクションの数を増やすことができ、プライバシーの安全策を強化することができます。
プライバシーインフラの終わり
上記の前提を考慮すると、ブロックチェーンのプライバシーインフラの最終的な目標は何でしょうか?すべてのアプリケーションに万能なアプローチはあるのでしょうか?すべてのアプリケーションを統一できるプライバシー強化技術はあるのでしょうか?
正確ではない。これらにはすべて異なるトレードオフがあり、さまざまな方法でそれらが組み合わされるのを見てきた。全体として、我々は11の異なるアプローチを特定した。
現在、ブロックチェーンでプライバシー基盤を構築するための2つの最も一般的なアプローチは、ZKPまたはFHEを活用することです。 しかし、どちらも根本的に欠陥があります。
クライアント証明のあるZKに基づくプライバシープロトコルは、強力なプライバシー保証を提供しますが、複数のパーティが同じ秘密状態で計算することはできません。これは、開発者がどのような種類のアプリケーションを構築できるかという点で、表現力を制限することになります。
FHEは暗号化されたデータと共有されたプライベート状態での計算をサポートしますが、誰が状態を所有するか、つまり誰が復号鍵を所有するかという問題が生じます。これは、プライバシーの保証の強さと、今日プライベートであるものが明日もそうであると信頼できる範囲を制限します。
理想的な最終状態が、共有されたプライベートな状態を単一障害点なしで扱える、プログラム可能なプライバシー インフラストラクチャを持つことであるならば、どちらの道もMPCにつながります:
2つのアプローチは最終的には収束しますが、MPCは異なる目的で使用されることに注意してください:
議論はよりニュアンスのある見方に向かい始めていますが、これらの異なるアプローチの背後にある保証については、まだ十分に調査されていません。
MPCプロトコルがブロックチェーンで提供できるプライバシー保証はどの程度強固なのでしょうか?
技術は十分に成熟していますか?十分でない場合、ボトルネックは何でしょうか?
保証の強さとそれがもたらすオーバーヘッドを考えると、他のアプローチと比べて意味があるのでしょうか?
これらの質問に詳しく答えましょう。
MPCによるリスクと脆弱性の分析
ソリューションがFHEを使用する場合、常に「誰が復号鍵を持っているのか?".その答えが「ネットワーク」である場合、次の質問は「ネットワークを構成する実際のエンティティは何か?.後者の質問は、何らかの形でMPCに依存するすべてのユースケースに関連しています。
Source:Zama's talk at ETH CC
MPCの主なリスクは共謀であり、十分な参加者が悪意を持って共謀し、データを解読したり計算を盗んだりすることです。共謀はオフチェーンで合意することができ、悪意のあるパーティが何らかの明らかな行動(恐喝、無からトークンを鋳造するなど)を取ったときに初めて明らかになります。言うまでもなく、これはシステムが提供できるプライバシー保証に大きな影響を与えます。
プロトコルは何人の悪意のあるパーティーに耐えられるか?
ネットワークを構成するパーティは何か?彼らはどれくらい信頼できますか?
ネットワークに関わるさまざまな当事者の数とその分布 - 共通の攻撃ベクトルはあるか?
ネットワークはライセンスレスか、ライセンスが必要か(金銭的利益対評判/法的根拠)?
悪意のある行動に対する罰則は?談合賭博は理論的に最適な結果なのか?
1.MPCプロトコルがブロックチェーンで提供できるプライバシー保証はどの程度強固ですか?
TLDR:私たちが望むほど強力ではありませんが、中央集権的なサードパーティに頼るよりは強力です。
復号に必要な閾値は、選択されたMPCスキームに依存します。これは、activity(「出力配信の保証」)とセキュリティの間のトレードオフです。非常に安全なN/Nスキームを持つことができますが、1つのノードがオフラインになるとすぐにクラッシュします。一方、N/2またはN/3スキームはより堅牢ですが、共謀のリスクが高くなります。
秘密情報は決して漏洩しない(例えば、復号キー
)
バランスが必要な2つの条件は次のとおりです。
秘密情報は決してなくならない(参加者の1/3が突然脱退しても)。
選択されるオプションは実装によって異なります。たとえば、ZamaはN/3を目指していますが、Arciumは現在N/Nスキームを実装していますが、より高いアクティビティ保証(およびより大きな信頼前提)を持つスキームを後でサポートする予定です。
このトレードオフの境界での妥協点は、ハイブリッドソリューションを目指すことです。
これは理論的には魅力的ですが、計算委員会が高信頼委員会とどのように相互作用するかなど、さらなる複雑さももたらします。
セキュリティを強化するもう一つの方法は、信頼できるハードウェアの中でMPCを実行し、キーシェアが安全な場所に保管されるようにすることである。これにより、プロトコルの定義以外の目的でキーシェアを抜き取ったり使用したりすることがより難しくなる。少なくともZamaとArciumはTEEの角度を探っている。
より微妙なリスクとしては、ソーシャルエンジニアリングのようなエッジケースもあります。
2.技術は十分に成熟しているか?そうでない場合、何がボトルネックになっているのでしょうか?
性能の観点から見ると、MPCの重要な課題は通信オーバーヘッドです。これは、計算の複雑さとネットワーク内のノード数(より多くの往復通信を必要とする)によって増大します。
小さな演算子セット:通信オーバーヘッドを管理しやすくするため、既存のプロトコルのほとんどは現在、小さな演算子セットに制限されています。例えば、Zamaの復号化ネットワークでは現在4ノードまでしか利用できない(16ノードまで拡張する予定だが)。Zama社が発表した復号ネットワーク(TKMS)の初期ベンチマークによると、わずか4ノードのクラスタでも復号にかかる時間は0.5~1秒である(完全なe2eプロセスにはもっと時間がかかる)。もう一つの例は、ワールドコインの虹彩データベースに対するTaceoのMPC実装で、3つのパーティがあります(2/3の正直なパーティを想定)。
Source:Zama's presentation at ETH CC
>Licensed Operator Sets: ほとんどの場合、オペレーターセットはライセンスを取得しています。これは、経済的または暗号的なセキュリティではなく、評判と法的契約に依存していることを意味します。ライセンスされていない演算子セットの主な課題は、人々が連鎖の下で共謀しているかどうかを知る方法がないことです。さらに、ノードが動的にネットワークに出入りできるように、定期的なブートストラップや鍵共有の再分配が必要となる。パーミッションレス・オペレーター・セットが最終的な目標であり、PoSメカニズムを拡張して閾値MPC(例えばZama)を可能にする研究が進行中ですが、パーミッションド・ルートが今のところ最善の方法のようです。
代替案
完全なプライバシーのポートフォリオには以下が含まれます:
複雑で、多くの未踏の極限を導入し、多くのオーバーヘッドがある。この先何年も実用化できないかもしれない。もうひとつのリスクは、複数の複雑な概念を重ねることで、人々が誤った安心感を抱いてしまうことだ。複雑さと信頼の前提が増えれば増えるほど、全体的なソリューションの安全性を推し量ることが難しくなります。
それだけの価値があるのか?その価値はあるかもしれませんが、プライバシーの保証をわずかに弱めるだけで、著しく優れた計算効率をもたらすかもしれない他のアプローチを探求する価値もあります。SeismicのLyronが指摘するように、私たちは、そのためだけに過剰なエンジニアリングを行うのではなく、望ましいプライバシーレベルと許容可能なトレードオフの基準を満たす最もシンプルなソリューションに焦点を当てるべきです。
1.MPCを一般的な計算に直接使用する
ZKとFHEが最終的にMPCの信頼の仮定に立ち戻るのであれば、なぜMPCを計算に直接使用しないのでしょうか?これは正当な疑問であり、Arcium、SodaLabs( Coti v2で使用)、 Taceo、Nillionなどのチームがやろうとしていることです。MPC にはさまざまな形式がありますが、3 つの主要なアプローチのうち、ここでは復号に MPC を使用する FHE ベースのプロトコルではなく、Secret Sharing と Glitch Circuits (GC) に基づくプロトコルを指します。
MPCは分散署名やより安全なウォレットなどの単純な計算に使用されてきましたが、MPCをより一般化された計算に使用する際の主な課題は、通信オーバーヘッド(これは計算の複雑さや関係するノードの数によって増加します)です。
オーバーヘッドを減らす方法があります。例えば、前処理(つまりプロトコルの最も高価な部分)をオフラインで事前に行うことです。その後、オンライン・フェーズで計算が実行され、オフライン・フェーズで生成されたデータの一部が消費される。これにより、全体的な通信オーバーヘッドが大幅に削減される。
SodaLabsの次の表は、そのgcEVMで異なるオペコードを1,000回実行するのにかかる時間のマイクロ秒単位での初期ベンチマークを示しています。これは正しい方向への一歩ではありますが、効率を改善し、演算子のセットを数ノード以上に拡張するためには、まだやるべきことがたくさんあります。
Source: SodaLabs
ZKベースのアプローチの利点は、共有プライベート状態で計算する必要があるユースケースにのみMPCを使用することです。
2.信頼された実行環境
最近、TEEへの関心が再燃しています。TEE単独(TEEベースのプライベート・ブロックチェーンまたはコプロセッサ)、またはZKベースのソリューション(ZK)など他のPETとの組み合わせのいずれかです。ZKベースのソリューション)、または他のPET(ZKベースのソリューションなど)との組み合わせ(共有プライベート状態の計算にのみTEEを使用)のいずれかである。
TEEはある意味でより成熟しており、パフォーマンスオーバーヘッドの導入も少ないですが、欠点がないわけではありません。まず、TEEは信頼性の前提が異なり(1/N)、ソフトウェアベースではなくハードウェアベースのソリューションを提供します。よく耳にする批判は、SGXの過去の脆弱性にまつわるものですが、TEE≠インテルSGXであることは注目に値します。 TEEはまた、ハードウェアプロバイダに対する信頼も必要としますが、これは高価です(そして、ほとんどの人にとって手が届きません)。物理的な攻撃のリスクに対する1つの解決策は、ミッションクリティカルなタスクのために宇宙空間でTEEを実行することかもしれません。
全体として、TEEは短期的なプライバシー(閾値復号、ダーク台帳など)しか必要としない証明やユースケースに適しているようです。永続的または長期的なプライバシーには、セキュリティはあまり魅力的ではないようです。
3.プライバシーを保護するために信頼できるサードパーティに依存するプライベートDACやその他のアプローチ
仲介プライバシーは、他のユーザーによるアクセスからプライバシーを提供できますが、プライバシー保証は完全にサードパーティを信頼することから得られます(単一障害点)。プライバシーの保証は、完全にサードパーティへの信頼から得られる(単一障害点)。
仲介プライバシーは、他のユーザーによるアクセスからのプライバシーを提供することができますが、プライバシーの保証は、完全にサードパーティを信頼することから得られます(単一障害点)。
プライベートデータアベイラビリティ委員会(DAC)はその一例です。DACのメンバーはデータをチェーンの下に保存し、ユーザーはデータを正しく保存し、状態遷移の更新を実行することを信頼します。別の形としては、トム・ウォルポが提案したチャータード・シーケンサーがある。
このアプローチは、プライバシーの保証という点では大きなトレードオフをもたらしますが、コストとパフォーマンスという点では(少なくとも現時点では)、低価値で高性能なアプリケーションにとって唯一の実行可能な選択肢かもしれません。例えば、Lens Protocolはプライベート・メッセージのストリーミングにプライベートDACを使用する予定だ。オンチェーンソーシャルなどのユースケースでは、プライバシーとコスト/パフォーマンスのトレードオフは、(代替案のコストとオーバーヘッドを考えると)今のところ妥当かもしれません。
4.ステルスアドレス
ステルスアドレスは、トランザクションごとに新しいアドレスを作成するのと同様のプライバシー保証を提供しますが、そのプロセスはバックエンドで自動化され、ユーザーには公開されません。詳細については、Vitalikによるこの概要、または異なるアプローチを掘り下げたこの記事を参照してください。
ステルスアドレスは比較的シンプルなソリューションを提供しますが、主な欠点は、トランザクション(支払いと送金)にのみプライバシー保証を追加できることであり、汎用的な計算には追加できません。これは、上記の他の3つのソリューションとは一線を画しています。
さらに、ステルスアドレスによって提供されるプライバシー保証は、他の選択肢ほど強力ではありません。匿名性は、特に送受信が同じような範囲にない場合(例えば、1万ドルを受け取ったが、1日平均10~100ドルを取引に使った)、単純なクラスター分析によって破られる可能性があります。ステルス・アドレスのもう一つの課題は鍵のアップグレードであり、現在ではウォレットごとに個別のアップグレードが必要である(キーストアのアグリゲーションがこれに役立つ)。ユーザーエクスペリエンスの面では、ステルスアドレスプロトコルは、アカウントが手数料トークン(例えばETH)を持っていない場合、アカウントのアブストラクタまたはペイヤーが手数料を支払う必要もあります。
私たちの主張に対するリスク
MPCが究極のソリューションになるという私たちの主張には、開発の急速なペースと、さまざまな技術的ソリューションをめぐる一般的な不確実性を考えると、多くのリスクがあります。
私的状態の共有は、私たちが考えているほど重要ではありません。ZKベースのインフラは、FHEよりも強力なプライバシー保証があり、オーバーヘッドが少ないため、このケースでは勝つ可能性が高い。
パフォーマンスのトレードオフは、プライバシー保証の利点に見合うものではありません。参加者は大差なく、コスト/オーバーヘッドの大幅な増加はそれに見合わないと主張するかもしれない。多くのアプリケーション、特に低価値でコストに敏感なアプリケーション(ソーシャルやゲームなど)については、これは真実かもしれない。しかし、法的な問題や高い調整摩擦のために、コラボレーションが現在非常に高価である(または不可能である)多くの高価値のユースケースもあります。後者は、MPCとFHEベースのソリューションが輝ける場所です。
専門化はユニバーサルデザインに優先する:新しいチェーンを構築し、ユーザーや開発者のコミュニティを立ち上げることは非常に困難です。その結果、普遍的なプライバシー・インフラストラクチャ(L1/L2)は支持を得るのに苦労するかもしれません。もう1つの問題は特殊化に関するものです。単一のプロトコル設計でトレードオフ空間全体をカバーすることは困難です。この世界では、既存のエコシステム(confidentiality-as-a-service)や特化したユースケース(例:支払い)に対してプライバシーを提供するソリューションが優勢になるでしょう。しかし、後者については、アプリケーション開発者に複雑さをもたらすため、私たちは懐疑的です。なぜなら、アプリケーション開発者は、暗号の一部を(抽象化するのではなく)自分で実装する必要があるからです。
規制は引き続きプライバシーソリューションの実験を妨げています。非金融的なユースケースは規制上のリスクは少ないが、ライセンスを必要としないプライバシー・インフラストラクチャの上に構築されるものをコントロールするのは難しい(不可能)だ。規制の問題を解決する前に、技術の問題を解決することになりそうです。
MPCおよびFHEベースのソリューションのオーバーヘッドは、ほとんどのユースケースにはまだ高すぎます。MPCは主に通信のオーバーヘッドに悩まされていますが、FHEチームはパフォーマンスを向上させるためにハードウェアアクセラレーションに大きく依存しています。しかし、ZK側の専用ハードウェアの開発を外挿できるとすれば、量産可能なFHEハードウェアができるまでには、多くの人が考えているよりもずっと長い時間がかかるだろう。
概要
結局のところ、チェーンの強さはその最も弱いリンクに依存します。最も弱いリンクに依存します。プログラム可能なプライバシー インフラストラクチャの場合、単一障害点なしで共有されたプライベート状態を処理できるようにしたいのであれば、信頼保証はMPC保証に帰着します。
この記事はMPCに批判的に聞こえますが、そうではありませんし、MPCは中央集権的なサードパーティに依存している現状を大きく改善するものです。主な問題は、業界全体に誤った信頼感があり、問題が覆い隠されていることだと考えている。そうではなく、問題に正面から向き合い、潜在的なリスクを評価することに集中すべきです。
しかし、すべての問題を同じツールを使って解決する必要はない。我々はMPCを究極のゴールと考えていますが、MPC主導のソリューションのオーバーヘッドが高いままである限り、他のアプローチも実行可能な選択肢です。私たちが解決しようとしている問題の特定のニーズや特徴に最も適しているのはどのアプローチなのか、そしてどのようなトレードオフをするつもりなのかを常に考える価値があります。
世界最高のハンマーを持っていたとしても、必ずしもすべてが釘になるわけではありません。