プログラム可能なプライバシー: コンプライアンスにさらに配慮する方法 Web3の世界へ

Ola では、a16z の記事「」の声明に強く同意します。 暗号通貨のプライバシーと規制遵守の実現「web3について：

「開発と規制は、 ウェブ3 – 暗号通貨によるインターネットの進化 – は、しばしば緊張関係にある 2 つの目標を達成する必要があります。目標 1:ブロックチェーンのデフォルトの透明性にもかかわらず、消費者のプライバシーを保護します。目標 2: 国家安全保障のために違法金融のリスクを軽減する。」

このビジョンは、Ola が記事で説明した内容と一致しています。 Ola – 独自の Web3 の旅を形作るさらに、高スループットを重視することは、Ola が現在実装に熱心に取り組んでいる機能です。

プライベートなシナリオを扱うか非プライベートなシナリオを扱うかにかかわらず、プログラマビリティは非常に重要な属性です。プログラム可能なプライバシーの分野では、Ola のほかに、Aztec と Miden の両方が同じ目標に向かって取り組んでいます。

オラさんの記事「 Sin7y Tech Review (35): ハイブリッド ロールアップ – 次世代インフラストラクチャ – HackMD 」では、これら 3 つのソリューションの違いについて説明します。

この記事では、コンプライアンスに配慮したという観点から Ola の設計を説明することに重点を置きます。 a16z の記事で説明されているように、プライバシーには次の 2 つの属性が同時に含まれる必要があります。

1. ネイティブのプライバシー保護を実現してユーザー情報を保護します。

   
   

2. 法規制を遵守して違法行為を追跡します。

最初のポイントは比較的簡単に達成できます。 2 つ目に関しては、どのプロジェクトにも独自の考慮事項とトレードオフがあります。ここでは主に、規制遵守に関する Ola の思考プロセスと設計について詳しく説明します。

現実世界の問題を解決するという観点からこれにアプローチし、まず規制遵守の観点からさまざまなプライバシー プロジェクトが直面する課題を検討してみましょう。記事の「非自発的選択的匿名化解除」の章で説明されているように、 ゼロ知識証明を使用したプライバシー保護規制ソリューション: フルペーパー - a16z 暗号重要な質問は次のとおりです。「トレーサビリティを解除するための秘密鍵は誰が管理するのか?」 」

トレーサビリティを解除するために秘密キーが必要なのはなぜですか?

トレーサビリティを実現するための秘密キーの必要性は、現在のプライバシー設計に関連しています。

現在、zk (ゼロ知識) テクノロジーに基づくほぼすべてのプライバシー ソリューションは Zcash からヒントを得ているため、以下に示すように、Zcash の設計について直接説明します。

記事では「 Sin7y Tech Review (33): プライベートトランザクションの原則と規制遵守の問題 - HackMD 」では、プライベート トランザクションの背後にある設計原則を確認できます。この設計の下でプライバシーがどのように維持され、規制上の懸念にどのように対処するかを簡単に説明します。

1. トランザクションの開始者または送信者の非表示: これは、本書のセクション 4.1.7.1 で詳しく説明されているように、1 回限りの署名によって実現されます。 zcash-苗木プロトコル。

   
   

2. トランザクション受信者または受信者を非表示にする: これは 2 つのシナリオに分かれています。

   
   

ⅰ．第三者からの隠蔽は、受信者のパブリック アドレスを使用して取引情報を暗号化することで実現されます。セクション 4.19.1 を参照してください。 zcash-苗木プロトコル。次に、受信者は、秘密キー (受信ビュー キーと呼ばれる) を使用してトランザクションを選別し、送信されたトランザクションを復号化し、フィルターで除外します。これについては、本書のセクション 4.19.2 で説明されています。 zcash-苗木プロトコル。トランザクションの内容自体には、受信者に関する情報は含まれません。

Ⅱ．同じ送信者からの隠蔽は、1 回限りのパブリック アドレスを使用して実現されます。

3. 取引情報の隠蔽の場合: このアプローチには、ゼロ知識証明と共有秘密スキームの使用が含まれます。セクション 4.17 および 4.19 を参照してください。 zcash-苗木プロトコル。

   
   

4. 追跡不可能な実装の場合: このアプローチは、コミットメント (以降、「CM」と呼びます) ツリーとヌリファイアー (以降、「NF」と呼びます) ツリーの設計に基づいています。この設計は次の目的に役立ちます。

   
   

ⅰ．すべての UTXO (未使用トランザクション出力) は 1 つの CM と 1 つの NF に対応しますが、この 2 つの間には直接的なつながりはありません。

Ⅱ． CM ツリーと NF ツリーはどちらも追加専用のツリーです。

ⅲ. CM ツリーは UTXO の正当性を証明するために使用され、NF ツリーは UTXO の二重使用を防止します。

上記のプライバシー設計に基づいて、ユーザーは次のプライバシー保護機能の恩恵を受けることができます。

1. 各トランザクションは外部関係者には見えないままです。

   
   

2. トランザクション間の接続は追跡できません。

   
   

ユーザーにとって完璧なプライバシー保護設計のように思えます。ただし、現実に基づいて考えると、すべてのユーザーが真の合法的な意図を持って操作しているわけではありません。必要に応じて追跡可能性を実現するために、プライベートな取引の詳細の一部またはすべてを開示するメカニズムが整備されていなければなりません。

これは、規制当局が悪意のあるユーザーに対して措置を講じるのに役立ちます。そうしないと、この形式のプライバシーが、悪意のある攻撃者が一般のユーザーに損害を与えるツールになる可能性があります。

前述のプライバシー設計により、規制当局は取引を追跡し、規制を施行することが容易になりますか?答えはいいえだ。提供された図 (参照されていますが、示されていません) に示されているように、現在のプライバシー設計では、トランザクション追跡可能性のロックを解除するためにビュー キーが必要です。

ただし、このビュー キーはユーザーが保持しているため、規制当局が直接アクセスすることはできません。これは、記事の「自発的選択的匿名化解除」および「非自発的選択的匿名化解除」というタイトルのセクション 13/14 で説明されている問題に関連しています。 ゼロ知識証明を使用したプライバシー保護規制ソリューション: フルペーパー - a16z 暗号。 」

さらに詳しく見てみましょう。ビュー キーはなぜ非常に機密性が高く、ユーザーが規制当局に提供することをためらうのでしょうか?

1. まず、ビュー キーがトランザクション署名に使用される秘密キーではないことを明確にすることが重要です。トランザクションに直接署名するために使用することはできないため、ユーザー資産を盗むために使用することはできません。

   
   

2. ビューキーが公開されると、規制当局はユーザーが開始したすべてのプライベートトランザクションを平文で見ることができます。ユーザーは、次の点について規制当局を信頼する必要があります。(1) ビューキーは漏洩しない。 (2) 取引の詳細は開示されません。

   
   

3. 当然ながら、悪意のある目的を持つユーザーはビュー キーを提供したがらないため、規制当局は無力になります。

   
   

上記の分析に基づいて、理想的なプライバシー ソリューションは次のとおりである必要があります。

1. 各トランザクションの内容を引き続き秘匿し、ユーザーのプライバシーが損なわれないようにします。

   
   

2. トランザクション間のパーミッションレスなトレーサビリティを実現します。これは、追加情報を強制的に提供することなくトレーサビリティを実現できることを意味します。

これが、Ola が達成しようとしているビジョンです。それは、トレーサビリティをネイティブに組み込んだプログラム可能なプライバシーです。

Ola はプログラム可能なプライバシーにネイティブのトレーサビリティをどのように導入しますか?

上記のプライバシー ソリューションが直面する規制上の課題に対処するために、Ola は大胆に試みに挑戦し、具体的な設計の概要を示しました。核となる技術ポイントは次のように要約できます。

1. Nullifier ツリーは、トランザクションの追跡不可能性を実現するために導入されなくなりました。 Ola の設計では、トランザクションは追跡可能ですが、これはトランザクション自体のプライバシー属性を損なうことなく、暗号化の下で行われます。

   
   

2. 残りのコミットメント ツリーは、同じコミットメントに対する二重支出攻撃を防ぐために追加のprove ステートメントを導入することにより、元の追加専用モードから更新可能なモードに移行されます。これを図 2 に示します。

   
   

3. 更新可能なビュー キー メカニズムを組み込みます。これは、ビュー キーが公開されたときに、ユーザーがビュー キーを更新して、キーの更新後に作成された後続のプライベート トランザクションを復号化できないようにできることを意味します。図 3 に示すように:

   
   

zkDID/zkKYC プライバシーと規制の効果的なバランスをとる

ゼロ知識分散型識別子 (zkDID) は、プライバシー プラットフォームで重要な役割を果たします。ユーザーの法的アイデンティティ (法的 ID) を zkDID に変換する機能があります。たとえば、PSE プロジェクトでは、 アノン・アダール、Aadhaar カードをお持ちの方は zkDID を生成できます。

他の人にとって、zkDID は匿名であり、ユーザーの実際の身元情報を明らかにしません。この二重の特性により、プライバシー保護のための強力なツールが提供されます。

zkDID の実装レベルに関しては、プラットフォームの設計と要件に応じて、さまざまなレベルで発生する可能性があります。

1. プラットフォーム レベルの実装: セキュリティとコンプライアンスを確保するためにプラットフォームですべてのユーザーの ID を管理および検証する必要がある場合は、プラットフォーム レベルで zkDID を実装することがより適切な選択となる可能性があります。このようにして、プラットフォームは zkDID を ID 管理システムの一部として直接統合することができ、ユーザーの ID の検証と承認が可能になります。

   
   

   このアプローチにより、プラットフォーム全体にわたって一貫した ID 保護とプライバシー制御が可能になります。

   
   

2. アプリケーションレベルの実装: プラットフォームがユーザー制御と柔軟性を優先する場合は、プラットフォーム上の上位層アプリケーションに zkDID を実装することが望ましい場合があります。この方法を使用すると、ユーザーは zkDID を使用するかどうかを選択し、必要に応じて ID を管理できます。

   
   

   ユーザーは、プライバシーと利便性のバランスをとるために、いつ zkDID を使用するかを決定できます。このアプローチは、自分の ID をより積極的に制御したいユーザーに適している可能性があります。 （非ネイティブ）。

上記の設計を考慮すると、Ola のプライバシー ソリューションには次の利点があります。

1. トレーサビリティ: 図 2 に示すように、トランザクション内の CM 情報に基づいて、第三者は CM のフロー パスを追跡できます。

   
   

2. プライバシー: 各トランザクションのプライバシーはそのまま残ります。送信者、受信者、その他の側面に関する情報は機密のままです。

   
   

3. 効率: 維持するツリーの数を減らすことで、zk-proof システムのオーバーヘッドが削減されます。

   
   

4. 更新可能なビュー キー: ビュー キーの更新をサポートし、ビュー キーが公開された場合でもトランザクションのプライバシーが侵害されないようにします。

   
   

5. コンプライアンスに優しい: 法的強制力のない情報を必要とせず、規制当局はターゲットの系統、たとえばどの CM コレクションに含まれるかを追跡できます。規制当局はこれらの CM の所有者に関する知識が一時的に不足している可能性がありますが、選択肢は 2 つあります。

   
   

6. ａ． CM が消費され、パブリック アドレスに転送されるまで待ちます。Ola の設計では、エコシステムを終了する前にすべてのプライベート ステートがパブリック ステートに移行する必要があるため、これは実現可能です。

   
   b. Zcash、Aleo、Aztec、Miden などのシステムで見られるように、プライバシー保護ソリューションのトレーサビリティに使用される従来の方法である復号化のためのビュー キー情報を取得します。

これらの技術的な利点以外にも、Ola は「」のような論文と統合できます。 暗号通貨のプライバシーと規制遵守の実現 - a16z crypto " そして "ブロックチェーンのプライバシーと規制遵守: 実質的な均衡に向けて」 ブラックリスト メカニズムやその他の初期段階の制約を組み込み、プログラム可能なプライバシー システム全体の設計を洗練します。

ここでも公開されています