数か月前、a16zの暗号チームが公開しましたナカモトチャレンジ,ブロックチェーンで解決すべき最も重要な問題のリスト。特に注目すべきは4番目の「コンプライアンス可能なプログラム可能なプライバシー」であり、私たちはこれについて長い間積極的に考えてきました。今日、私たちは同型暗号化を使用した初の解決策と、fhEVM機密スマートコントラクトプロトコルを提案しています（fhEVMについて詳しく知りたい場合は、機密関連の記事を読んでください。ERC20トークンそしてブラインドオークション。

fhEVMは、当社のTFHE-rsホモモーフィック暗号化ライブラリを使用して暗号化された状態で計算を可能にするいくつかの事前コンパイルを備えた通常のEVMです。開発者の視点からは、暗号化は関係ありません：彼らは単に、当社が提供する暗号化データ型（euint32、eboolなど）を使用してSolidityコードを記述します。 fhEVMの大きな利点の1つは、他のプライバシーソリューションと比較して、すべてのデータと計算がオンチェーンで行われることです。これにより、通常のプレーンテキスト契約と同じレベルの合成性とデータの利用可能性を持つことができます。

この特性は、プログラマブルプライバシーの構築に不可欠であり、すべてのアクセス制御ロジックを契約自体で定義できます。プロトコルにハードコードする必要はなく、ユーザーがコンプライアンスを遵守するためにオフチェーンで行う必要もありません。アプリケーションは、わずか数行のSolidityコードでコンプライアンスを直接強制できます！

この記事では、オンチェーンDIDを使用してコンプライアントなERC20トークンを構築する方法を紹介します。このチュートリアルのソースコードは、で見つけることができます。例フォルダfhEVMリポジトリの

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

分散型識別子（DID）は、政府、登録機関、企業、またはユーザー自身などの実体によって発行される一意のデジタル身元証明です。このDIDは、EVMウォレットなど、ユーザーがDIDを所有していることを証明する暗号キーに関連付けることができます。しかし、ユーザーの年齢、国籍、社会保障番号などのさまざまな属性を格納することもできます。これらの属性は、18歳以上であることやナルニア市民でないことなどの条件を満たしていることを証明するために使用できます（これを「証明」と呼びます）。

ほとんどのDIDはクライアント側で実装され、ゼロ知識証明を使用して証明書を生成します。これは多くの場合には問題ありませんが、複数のユーザーが取引に関与する場合、DIDに複雑なルールを適用する必要がある場合、または全員が従う共通のルールを保持する必要がある場合、すぐに複雑になります。基本的には、エッジ対クラウドアプリケーションでの同じトレードオフです。

中央集権的なDIDレジストリを持つことで、これらの問題を解決できます。登録機関に対して簡単にコンプライアンスを確認するよう依頼できます。規制を追跡することも簡単になります。1か所に実装するだけで済むためです。このためには、ブロックチェーンが完璧なインフラストラクチャになります。DIDとコンプライアンスが必要なアプリケーション、および規制同士の相互運用性を実現します。

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

幸いなことに、解決策があります：同型暗号化、そしてより具体的にはfhEVM！ 暗号化された状態で合成可能である能力のおかげで、ユーザーのDIDを直接暗号化形式でオンチェーンにホストし、コンプライアンスのアプリケーションが属性を簡単な契約呼び出しを使用して検証できるようになりました。 「Identity Abstraction」と呼ぶスマートコントラクトを介してアイデンティティを管理する能力は、アカウント抽象化を使用して資金を管理できる方法に類似しています。

このチュートリアルは3つのパートに分かれています。

• Identity Abstractionは、アイデンティティと証明の管理を担当する登録契約によって行われます。ここでは、DIDが公式の政府IDであると仮定しています。登録自体は中央機関（例：AFNIC）によって管理され、登録機関（例：Onfido、JumioなどのKYC企業）を作成できる権限があります。その後、登録機関はユーザーのDIDを作成できます。ユーザーはその後、登録機関を通じて自分のDIDを管理および更新します。
• 規制は、個人間のトークンの転送に関するルールセットをエンコードした契約で定義され、それらのDIDに含まれる情報に基づいています。基本的には、ユーザーレベルではなく契約レベルで規制を強制します。
• コンプライアンスに準拠した機密転送は、規制契約を使用してトークン転送のコンプライアンスを強制するコンプライアンスに準拠したERC20契約に実装されています。 ERC20 API自体に変更はありません。この例では、機密ERC20契約を使用しており、残高と金額が非表示になっていますが、通常の平文ERC20トークンでも同様に機能します。

私たちのオンチェーン機密DIDプロトコルのアーキテクチャ

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

IdentityRegistryコントラクトは、登録機関によって発行されたユーザーのDIDのレジストリであり、国籍、年齢、社会保障番号などの一連の暗号化された識別子を含みます。 これらの識別子は、暗号化された32ビットの値（euint32）として保存されています。

契約はまた、次のような権限も処理します：

• 契約所有者（例：AFNIC）がレジストラを追加、削除、または更新できるようにする
• 登録機関が作成したユーザーDIDを追加、削除、または更新できるようにする。
• ユーザーがスマートコントラクトにDIDの特定の属性へのアクセスを許可することを可能にします。ここで重要なのは、ユーザーが悪意のある契約にアクセス権を与えないようにする責任があるということです。まるで悪意のある契約がトークンを使わせない責任があるのと同じように。

最初のステップとして、DIDの作成と管理のためのロジックを実装しましょう。

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

識別子は単純に文字列（例：「生年月日」）と暗号化された32ビットの値です。登録者のみが作成または更新できます。ユーザーは自分で識別子を作成できません。登録者によって認定されるようにしています。

識別子が暗号化されているため、ユーザーは特定の値にアクセスするために契約に許可を与える必要があります。これは、契約がERC20トークンを支出することを許可する方法と類似したシンプルなアクセス制御メカニズムを介して処理します。

契約IdentityRegistryはEIP712WithModifier、Ownableです

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

contract IdentityRegistryは、EIP712WithModifier、Ownableです

規制契約

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

2人間の間での転送のためのルールセットを実装する際には、これらのルールが時間とともに進化する可能性があることを認識することが重要です。 お金の送金などの特定のコンテキストのためのすべての規制を定義する単一のスマートコントラクトを持つことは、ERC20コントラクトが規制を自分で追跡する必要がないことを意味します。 政府は単にこの契約を更新すればよく、それは実装したすべてのトークンに自動的に伝播します。

基本的に、規制契約は、暗号化されたアイデンティティ属性に一致する条件のセットに過ぎません。誤用を避けるために、ユーザーは規制契約に直接アクセス権を付与せず、代わりにERC20トークン契約にアクセス権を付与し、その後、代理呼び出しを規制契約に行います。このアプローチにより、ユーザーが信頼するERC20契約のみが彼らの情報にアクセスできることが保証されます。送信者と受信者の両方が、トランスファーが行われる前にERC20契約に許可を与える必要があることに注意してください。

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

• 国内での送金は制限がないが、外国への送金は1万トークンに制限されています。
• ブラックリスト入りしたユーザーはトークンの送受信ができません。
• ユーザーはトークンをブラックリストに登録された国に送金することはできません。

取引に失敗する代わりに、機密情報を明らかにする可能性があるため、条件のいずれかが満たされていない場合は単に転送金額を0に設定します。これには、cmuxと呼ばれる同型三項演算子が使用されます: value = TFHE.cmux(encryptedCondition, valueIfTrue, valueIfFalse)

コンプライアンス準拠の機密性の高いERC20契約

これで、アイデンティティ登録と規制契約ができたので、ついに、準拠しており、プライバシーを保護するトークン契約を作成することができます。この契約はCompliantERC20と呼ばれ、次の主な特徴を持ちます。

• ユーザーの残高と送金額は暗号化されています。
• コンプライアンスは、規制コントラクトを呼び出すことで転送時に強制されます。
• 特定の残高の可視性をホワイトリストに登録されたアドレス（例：規制機関）に付与することができます

規制契約は簡単な呼び出し経由で呼び出されます。これは、ユーザーが任意の転送を開始する前にERC20契約へのアクセス権限を提供する必要があることを意味します。そうでない場合、転送は元に戻されます。

ついに、私たちはERC20契約を作成することができます。

DeFiプロトコルにトークンの支出権限を付与するのと同様に、規制契約によって必要とされる識別子へのアクセス許可をユーザーが付与する必要があります。これはIdentity.grantAccess(contractAddress, identifiers)を呼び出すことで行われ、ERC20.identifiers()ビューメソッドを呼び出すことで取得できます。このリストは直接ERC20Rules契約から取得され、プロパティの更新を許可します。

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

このチュートリアルで、適切なツールがあれば、コンプライアンスは難しいものではないことがわかりました。最初はfhEVMを使ってブロックチェーンでプライバシーを実現することを目指していましたが、すぐにこの技術がアイデンティティ管理やプログラマブルコンプライアンスにも利用できることに気づきました。

提案されたデザインここは完璧とは程遠いですが、私たちは簡単に改善して実際のユースケースとして立ち上げることができると信じています。そのため、コンプライアンスはもはや監視と同義ではないと考えています！

追加リンク

• スターZamaのfhEVMのGithubリポジトリ私たちの仕事を是認するために。
• レビューZamaのfhEVMドキュメント.
• 当社のサポートを受けるコミュニティチャンネル.
• ZamaバウンティプログラムでFHEスペースを前進させるのを手伝ってください：ZamaのfhEVMプログラマブルプライバシーを使用して、プライベートステートを隠したオンチェーンゲームを作成します (15,000€ in prize).

免責事項：

1. この記事は[から転載されましたzama]。すべての著作権は元の著者に帰属します[fhEVM]. If there are objections to this reprint, please contact the ゲート ラーンチームはすぐに対処します。
2. 責任の免除：この記事で表現されている意見はすべて著者個人のものであり、投資アドバイスを構成するものではありません。
3. Gate Learnチームによって他言語への記事の翻訳が行われています。特に記載されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。