FHEはa16zが提起したコンプライアンス可能なプライバシー問題をどのように解決しますか？

原文标题：《プログラム可能なプライバシーとオンチェーンコンプライアンスのための同態暗号の使用》

作者：Rand Hindi

編訳：Luccy，BlockBeats

編者按：

9月19日、a16zの暗号チームはNakamoto Challengeで7つの問題を提起しました。それは、原子性の組み合わせと共有シーケンシングの限界、DePINの検証、JOLT + Lasso問題、コンプライアンス可能なプログラム可能なプライバシー、最適なLVR緩和、MEV取引サプライチェーンの設計、そしてブロックチェーンを利用したディープフェイク保護です。

コンプライアンス可能なプログラム可能なプライバシーの問題に対して、オープンソースの暗号ツールZamaは、完全同態暗号（FHE）またはfhEVM機密スマートコントラクトプロトコルを提案しました。fhEVMは、暗号状態で計算を行う能力により、開発者に対してオンチェーンでコンプライアンス可能なプログラム可能なプライバシーアプリケーションを構築する新しい方法を提供します。

分散型識別子（DID）は、デジタルアイデンティティの発行者として、暗号状態に保存され、ユーザーのアイデンティティのプライバシーとプログラム可能なコンプライアンスのウィンウィンを実現します。規制契約を通じて個人間のトークン移転ルールを定義することで、送金条件の動的な監視を実現します。この設計は、スマートコントラクトレベルで規制要件を実行し、ハードコーディングを必要とせず、ユーザーは数行のSolidityコードでアプリケーションのコンプライアンスを確保できます。

ZamaのCEOであるRand Hindiは、記事の中で、fhEVMを使用してコンプライアンスのあるERC20トークンを構築する方法を示しました。彼は、他のプライバシーソリューションに対して、fhEVMのすべてのデータと計算がオンチェーンで行われるため、組み合わせ性とデータの可用性が保証されると指摘しました。

数ヶ月前、a16zの暗号チームはNakamoto Challenge（中本挑戦）を発表しました。これは、ブロックチェーンにおける最も重要な問題のリストです。その中で、4番目の問題が特に私たちの注目を集めました：「コンプライアンス可能なプログラム可能なプライバシー」です。なぜなら、私たちはこの問題について積極的に考えてきたからです。今日は、同態暗号とfhEVM機密スマートコントラクトプロトコルを使用した最初の解決策を提案します。

fhEVMは、いくつかのプレコンパイルを含む通常のEVMであり、私たちのTFHE-rs同態暗号ライブラリを使用して暗号状態で計算を行うことができます。開発者の観点からは、暗号学に関与することはなく、私たちが提供する暗号データ型（euint32、eboolなど）を使用してSolidityコードを書くことができます。fhEVMの他のプライバシーソリューションに対する大きな利点は、すべてのデータと計算がオンチェーンで行われることです。これは、通常の平文契約と同じ組み合わせ性とデータの可用性を得ることができることを意味します。

この機能は、すべてのアクセス制御ロジックが契約自体に定義できるため、プログラム可能なプライバシーを構築する上で重要です。プロトコルにはハードコーディングが必要な内容はなく、ユーザーはコンプライアンスを確保するためにオフチェーンで何かを実行する必要はありません。アプリケーションは、数行のSolidityコードでコンプライアンスを直接強制できます。

この記事では、オンチェーンDIDを使用してコンプライアンスのあるERC20トークンを構築する方法を示します。本チュートリアルのソースコードは、fhEVMリポジトリのexamplesフォルダにあります。

オンチェーンでの機密DIDによるアイデンティティ抽象化

分散型識別子（DID）は、政府、登録機関、企業、またはユーザー自身などのエンティティによって発行されるユニークなデジタルアイデンティティです。このDIDは、ユーザーがDIDを所有していることを証明する暗号鍵（例えばEVMウォレット）と結びつけることができます。しかし、ユーザーの年齢、国籍、社会保障番号などの一連の属性を保存することもできます。これらの属性は、年齢が18歳以上であるか、ナニア市民でないことなど、特定の条件を満たしていることを証明するために使用されます。政府、登録機関、企業、またはユーザー自身などのエンティティによって発行されます。

ほとんどのDIDは実際にはユーザー側で実装されており、ゼロ知識証明を利用して証明を生成します。多くの場合、これは可能ですが、複数のユーザーが取引に参加し、DIDに複雑なルールを適用する必要がある場合や、全員が共通のルールに従う必要がある場合、状況は複雑になります。これは本質的にエッジアプリケーションとクラウドアプリケーションのトレードオフに似ています。

しかし、集中型のDIDレジストリを持つことで、これらの問題を解決できます。なぜなら、レジストリに誰が規定を満たしているかを確認させるだけで済むからです。これにより、規制の追跡も簡単になります。なぜなら、1つの場所で実施するだけで済むからです。ブロックチェーンは、この理想的なインフラストラクチャとなり、DIDと規定に従う必要のあるアプリケーション間の組み合わせ性、さらには規定間の組み合わせ性を可能にします。これは本質的にエッジアプリケーションとクラウドアプリケーションのトレードオフに似ています。

問題：誰もが他のすべての人のアイデンティティを見ることができる！

幸いなことに、私たちには解決策があります：同態暗号、より具体的にはfhEVMです！暗号状態での組み合わせ性の能力により、ユーザーのDIDを暗号形式で直接オンチェーンにホスティングし、簡単な契約呼び出しを通じてコンプライアンスアプリケーションが属性を検証できるようにします。アイデンティティを管理する能力を持つスマートコントラクトを通じて、私たちはこれを「アイデンティティ抽象化」と呼びます。これは、アカウント抽象化を持つスマートコントラクトを通じて資金を管理する方法に似ています。

本チュートリアルは3つの部分に分かれています：

アイデンティティ抽象化は、アイデンティティと証明を管理する登録契約を通じて実現されます。ここでは、DIDが公式の政府IDであると仮定します。レジストリ自体は中央機関（例えばAFNIC）によって管理され、登録機関（例えばKYC会社、Onfido、Jumioなど）を作成できます。その後、登録機関はユーザーDIDを作成できます。ユーザーは登録機関を通じて自分のDIDを管理および更新します。

規制は、ユーザーDIDに含まれる情報に基づいて個人間のトークン移転ルールをコーディングする契約の中で定義されます。基本的に、これはユーザーレベルではなく契約レベルで規制を実行します。

コンプライアンスの機密転送は、コンプライアンスのERC20契約の中で実現されます。この契約は、トークン移転のコンプライアンスを強制するために規制契約を使用し、ERC20 API自体には何の変更も加えません。この例では、残高と金額が隠された機密ERC20契約を使用していますが、通常の平文ERC20トークンにも同様に適用できます。

アイデンティティ登録契約

アイデンティティ登録契約は、登録機関がユーザーDIDを発行するレジストリであり、国籍、年齢、社会保障番号などの一連の暗号識別子を含みます。これらの識別子は、暗号化された32ビット値（euint32）の形式で保存されます。

この契約は、権限も処理します。これには以下が含まれます：

契約の所有者（例えばAFNIC）が登録機関を追加、削除、または更新できるようにします。

登録機関が自分が作成したユーザーDIDを追加、削除、または更新できるようにします。

ユーザーがスマートコントラクトに特定の属性へのアクセス権を付与できるようにします。ここで注意が必要なのは、ユーザーは悪意のある契約にアクセス権を付与しない責任があるということです。これは、悪意のある契約に自分のトークンを使わせない責任と同じです。

第一歩として、DIDの作成と管理のロジックを実装します：

注：画像は一部のスクリーンショットであり、原文で完全なコードを確認できます。

次のステップは、識別とアクセス制御のロジックを実装することです。

識別子は、簡単に言えば、文字列（例えば「生年月日」）と暗号化された32ビット値です。これは登録機関によってのみ作成または更新できます。ユーザーは自分の識別子を作成できません。なぜなら、私たちはそれらが登録機関によって認証されることを望んでいるからです。

しかし、識別子は暗号化されているため、ユーザーは契約に特定の値へのアクセス権を付与する必要があります。これを、ERC20トークンを使わせるための簡単なアクセス制御メカニズムに似た方法で処理します。

注：画像は一部のスクリーンショットであり、原文で完全なコードを確認できます。

これで、必要なゲッターを追加し、いくつかの条件とエラーハンドリングを加えることで、アイデンティティ登録契約を完成させることができます。

注：画像は一部のスクリーンショットであり、原文で完全なコードを確認できます。

規制契約

次のステップは、規制契約を作成することです。

2つの個体間の転送ルールを実施する際に重要なのは、これらのルールが時間とともに進化する可能性があることを認識することです。特定の文脈（例えば資金移転）のすべての規制要件を定義する単一のスマートコントラクトがあると、ERC20契約は自分自身で規制要件を追跡する必要がありません。政府はこの契約を更新するだけで、それは自動的にそれを実施したすべてのトークンに広がります。

コア部分では、規制契約は暗号アイデンティティ属性に一致する条件のセットに過ぎません。悪用を防ぐために、ユーザーは規制契約に直接アクセス権を付与するのではなく、ERC20トークン契約にアクセス権を付与し、その後ERC20トークン契約が規制契約への委任呼び出しを実行します。この方法により、ユーザーが信頼するERC20契約のみが彼らの情報にアクセスできるようになります。送信者と受信者の間で転送が行われる前に、両者はERC20契約に許可を与えている必要があることを忘れないでください。

この例では、いくつかの基本的なルールを実施します：

国内の転送は制限なしですが、外国への転送の上限は1万トークンです。

ブラックリストに載っているユーザーはトークンを転送または受け取ることができません。

ユーザーはトークンをブラックリストの国に転送することはできません。

取引を失敗させるのではなく、機密情報が漏洩する可能性がある場合、条件の1つが満たされない場合は、単に転送金額を0に設定します。これは、cmuxという同態三項演算子を使用します：value = TFHE.cmux(encryptedCondition, valueIfTrue, valueIfFalse);

注：画像は一部のスクリーンショットであり、原文で完全なコードを確認できます。

コンプライアンスのプライバシーERC20契約

これで、アイデンティティ登録と規制契約が整ったので、ついに要求を満たし、プライバシーを保護するトークン契約を作成できます。この契約はCompliantERC20と呼ばれ、以下の重要な特徴を持ちます：

ユーザーの残高と転送金額は暗号化されています。

コンプライアンスは規制契約を呼び出すことで転送を実行します。

ホワイトリストのアドレス（例えば規制機関）に特定の残高の可視性を付与できます。

規制契約を簡単に呼び出すことができます。これは、ユーザーが任意の転送を開始する前にERC20契約へのアクセス権を提供する必要があることを意味します。そうでなければ、転送はロールバックされます。

最後に、私たちはついにERC20契約を作成できます：

ユーザーがDeFiプロトコルに自分のトークンを使わせる権限を付与するのと同様に、彼らは契約に規制契約に必要な識別子へのアクセス権を付与する必要があります。これは、Identity.grantAccess(contractAddress, identifiers)を呼び出すことで実現され、ERC20.identifiers()ビューメソッドを呼び出すことで取得できます。このリストは、属性の更新を許可するためにERC20Rules契約から直接取得されます。

コンプライアンスとプライバシーは共存できる

適切なツールがあれば、コンプライアンスを確立することは難しくありません。私たちは最初にfhEVMをブロックチェーンでプライバシーを実現するために構築しましたが、この技術がアイデンティティ管理に利用できることにすぐに気付き、プログラム可能なコンプライアンスを実現しました。

この設計はまだ完璧ではありませんが、私たちはそれが改善を続け、コンプライアンスがもはや規制と同義ではないという真のユースケースとして展開できると信じています。