ハードウェア自体に関連するリスクを受け入れ る必要がある(例 : Intel SGXの侵害の可能 性)。 • TEEプロバイダーがアクティビティを制限しな いことを信頼する。 • ネットワークレベルの攻撃。これを克服するに は分散化が必要だが、 Intel SGXのようなTEE は一般消費者のデバイスでは広く利用できな いため、Intel SGXデバイスプロバイダーの IP が検出・ブロックされる可能性がある。 • プロキシがユーザーと共謀せず、悪意の ある行為者を迂回させないこと。 • 複数のプロキシと経済的インセンティブ、 スラッシングの利用によって共謀のリスクが 低減される。 • ユーザーが偽のコミットメントに署名するた めにNotaryと共謀しないこと。 • 現在の設計では計算オーバーヘッドのた め、単一のNotaryへの信頼が必要。 強み (Strengths) • 高効率で、計算およびネットワークのオー バーヘッドが最小限。 • サードパーティサービスプロバイダーなし でセットアップ可能。 • ほとんどのユースケースで高速かつ信頼 性が高い。 • 消費者デバイスで利用可能であり、最終 的には分散化を促進する。 • Bright Dataのような既存のプロキシネット ワークを活用して共謀のリスクを低減でき る(例: BGPハイジャッキング)。 • 高セキュリティ設計。 • MPCは、ユーザーがMPCベースのウェブ 証明を使用しているか標準のTLSを使用 しているかを検出しにくくするため、IPアド レスがユーザー自身のものとなり、ブロック のリスクを軽減する。 弱み (Weaknesses) • セキュリティはハードウェアのセキュリティ およびプロバイダーに完全に依存する。 • 消費者デバイスで利用可能なTEEが不足 しているため、分散化が困難。 • ウェブサイトは、リクエストがユーザーのIP アドレスではなくプロキシから送信されてい ることを検出し、スケール時にプロキシをブ ロックする可能性がある。 • ブロックを回避するためにIPを調達する必 要があり、これが共謀攻撃の可能性を開く が、IPを消費者デバイスに分散化すること で解決可能。 • 計算オーバーヘッドとそれに伴う遅延。リクエ ストの暗号化およびレスポンスの復号化には、 各MPCノードが共有鍵の一部を使って暗号化 /復号化を行う必要があり、遅延は MPCネット ワークのサイズに比例して増加する。 • TLSハンドシェイク時に発生する遅延が、どの IPがMPCベースのウェブ証明を使用している かを特定するために十分な場合があり、検出 されるとブロックされる可能性がある。