Il y a quelques mois, l'équipe cryptographique de a16z a publié le Défi Nakamoto, une liste des problèmes les plus importants à résoudre dans la blockchain. Le quatrième problème en particulier a retenu notre attention : “Confidentialité programmable conforme”, car nous réfléchissons activement à cela depuis un certain temps. Aujourd'hui, nous proposons une première solution utilisant le chiffrement homomorphique et notre protocole de contrat intelligent confidentiel fhEVM (si vous n'êtes pas familier avec le fhEVM, vous pouvez lire nos articles sur le confidentiel.jeton ERC20etVentes aux enchères à l’aveugle).

Le fhEVM est un EVM ordinaire avec quelques précompilations qui permettent de calculer sur des états chiffrés en utilisant notre bibliothèque de chiffrement homomorphique TFHE-rs. Du point de vue du développeur, il n'y a pas de cryptographie impliquée : ils écrivent simplement du code Solidity en utilisant les types de données chiffrés que nous fournissons (euint32, ebool, etc). Un des grands avantages du fhEVM par rapport à d'autres solutions de confidentialité est que toutes les données et les calculs se font onchain. Cela signifie que vous pouvez avoir le même niveau de composabilité et de disponibilité des données que pour les contrats réguliers en texte clair.

Cette propriété est essentielle pour construire une confidentialité programmable, car toute la logique de contrôle d'accès peut être définie dans le contrat lui-même. Il n'y a rien qui doit être codé en dur dans le protocole et rien que l'utilisateur doit faire hors chaîne pour être conforme. L'application peut appliquer la conformité directement, avec seulement quelques lignes de code Solidity !

Dans cet article, nous montrerons comment construire un jeton ERC20 conforme, en utilisant des DIDs onchain. Le code source de ce tutoriel peut être trouvé dans le dossier d'exemplesdu référentiel fhEVM.

Abstraction de l’identité via des DID confidentielles onchain

Un identifiant décentralisé (DID) est une identité numérique unique délivrée par une entité telle qu'un gouvernement, un registraire, une entreprise ou l'utilisateur lui-même. Ce DID peut être lié à une clé cryptographique prouvant que l'utilisateur possède le DID, comme un portefeuille EVM. Mais il peut également stocker toute une série d'attributs, tels que l'âge de l'utilisateur, sa nationalité, son numéro de sécurité sociale, etc. Ces attributs peuvent ensuite être utilisés pour prouver que vous remplissez une certaine condition (appelée « attestation »), comme avoir plus de 18 ans ou ne pas être citoyen de Narnia.

La plupart des DIDs sont implémentés côté client et utilisent des preuves de connaissance nulle pour générer des attestations. Bien que cela soit acceptable dans de nombreux cas, cela devient rapidement compliqué lorsque vous avez plusieurs utilisateurs impliqués dans une transaction, lorsque vous devez appliquer des règles complexes au DID, ou lorsque vous devez conserver un ensemble commun de règles pour que tout le monde les suive. C'est essentiellement le même compromis que dans les applications de bord par rapport aux applications cloud.

Avoir un registre DID centralisé résoudrait cependant ces problèmes, car vous pourriez simplement demander au registre de vérifier que tout le monde est conforme. Cela rendrait également plus simple le suivi des réglementations, car vous auriez seulement besoin de l'implémenter à un seul endroit. Une blockchain serait une infrastructure parfaite pour cela, car elle permettrait la composabilité entre les DIDs et les applications nécessitant la conformité, ainsi que la composabilité entre les réglementations elles-mêmes.

Problème : tout le monde verrait l'identité de tout le monde !

Heureusement, nous avons une solution : le chiffrement homomorphique, et plus précisément le fhEVM ! Grâce à la capacité d'avoir une composition sur un état chiffré, nous pouvons héberger les DIDs de l'utilisateur directement onchain sous forme chiffrée, et avoir des applications conformes vérifiant les attributs en utilisant un simple appel de contrat. La capacité de gérer une identité via un smart contract, que nous appelons "Abstraction d'identité", est semblable à la manière dont on peut gérer des fonds via un smart contract avec l'Abstraction de compte.

Ce tutoriel comporte 3 parties:

• L'abstraction de l'identité est réalisée via un contrat de registre qui est responsable de la gestion des identités et des attestations. Ici, nous supposons que les DIDs sont des identifiants gouvernementaux officiels. Le registre lui-même est géré par une autorité centrale (par exemple l'AFNIC) qui peut créer des registrars (par exemple des entreprises de KYC telles que Onfido, Jumio, etc.) qui peuvent ensuite créer des DIDs d'utilisateur. L'utilisateur passe ensuite par son registrar pour gérer et mettre à jour ses DIDs.
• La régulation est définie dans un contrat qui encode un ensemble de règles pour les transferts de jetons entre individus, basé sur les informations contenues dans leurs DIDs. Elle applique essentiellement la régulation au niveau du contrat plutôt qu'au niveau de l'utilisateur.
• Les transferts confidentiels conformes sont mis en œuvre dans un contrat ERC20 conforme qui utilise le contrat de régulation pour garantir la conformité des transferts de jetons, sans apporter de modifications à l'API ERC20 elle-même. Dans cet exemple, nous utilisons un contrat ERC20 confidentiel, où les soldes et les montants sont cachés, mais cela fonctionnerait tout aussi bien avec un jeton ERC20 régulier et en texte clair.

Architecture de notre protocole DID confidentiel Onchain

Le contrat de registre d'identité

Le contrat IdentityRegistry est un registre des DIDs d'utilisateurs qui sont émis par des registrars et comprennent un ensemble d'identifiants chiffrés, tels que leur nationalité, leur âge, leur numéro de sécurité sociale, etc. Ces identifiants sont stockés sous forme de valeurs chiffrées sur 32 bits (euint32).

Le contrat gère également les autorisations, telles que:

• Permettre au propriétaire du contrat (par exemple AFNIC) d'ajouter, de supprimer ou de mettre à jour les bureaux d'enregistrement.
• Permettre aux registrars d'ajouter, de supprimer ou de mettre à jour les DIDs des utilisateurs qu'ils ont créés.
• Permettant aux utilisateurs d'accorder aux contrats intelligents l'accès à des attributs spécifiques de leurs DIDs. Il est important de noter ici que l'utilisateur est responsable de ne pas donner accès à des contrats malveillants, tout comme il est responsable de ne pas laisser des contrats malveillants dépenser leurs jetons.

Dans un premier temps, implémentons la logique de création et de gestion des DID :

Maintenant, la prochaine étape consiste à mettre en œuvre la logique pour les identifiants et le contrôle d'accès.

Un identifiant est simplement une chaîne (par exemple "date de naissance") et une valeur de 32 bits chiffrée. Il ne peut être créé ou mis à jour que par le registraire. Un utilisateur ne peut pas créer ses propres identifiants, car nous voulons qu'ils soient certifiés par le registraire.

Étant donné que les identifiants sont chiffrés, l'utilisateur doit donner la permission à un contrat d'accéder à des valeurs spécifiques, que nous gérerons grâce à un mécanisme de contrôle d'accès simple similaire à la façon dont vous pouvez autoriser un contrat à dépenser vos jetons ERC20.

le contrat IdentityRegistry est EIP712WithModifier, Ownable

Nous pouvons maintenant finaliser notre contrat de registre d'identité en ajoutant les getters nécessaires, avec quelques conditions et gestion des erreurs.

le contrat IdentityRegistry est EIP712WithModifier, Ownable

Le contrat de réglementation

La prochaine étape consiste à créer notre contrat de conformité.

Lors de la mise en œuvre d'un ensemble de règles pour les transferts entre deux individus, il est important de reconnaître que ces règles peuvent évoluer avec le temps. Le fait d'avoir un seul contrat intelligent définissant toute la réglementation pour un contexte donné tel que le transfert d'argent signifie que les contrats ERC20 n'ont pas à suivre la réglementation eux-mêmes. Les gouvernements peuvent simplement mettre à jour ce contrat, et il se propagera automatiquement à tous les jetons qui l'ont implémenté.

Au cœur, le contrat de régulation n'est qu'un ensemble de conditions qui sont confrontées aux attributs d'identité chiffrés. Pour éviter les abus, les utilisateurs ne concèdent pas directement l'accès au contrat de régulation, mais accordent plutôt l'accès au contrat de jeton ERC20, qui effectue ensuite un appel délégué au contrat de régulation. Cette approche garantit que seul le contrat ERC20, en qui l'utilisateur a confiance, peut accéder à ses informations. Gardez à l'esprit que l'expéditeur et le destinataire doivent avoir tous deux accordé l'autorisation au contrat ERC20 avant qu'un transfert puisse avoir lieu entre eux.

Dans cet exemple, nous mettrons en œuvre quelques règles de base :

• Les transferts à l'intérieur d'un pays sont illimités, mais les transferts vers un pays étranger sont plafonnés à 10 000 jetons.
• Un utilisateur sur liste noire ne peut pas transférer ou recevoir de jetons.
• Un utilisateur ne peut pas transférer des jetons vers un pays blacklisté.

Plutôt que d'échouer la transaction, ce qui pourrait révéler des informations sensibles, nous allons simplement définir le montant du transfert à 0 si l'une des conditions n'est pas remplie. Cela utilise un opérateur ternaire homomorphique appelé cmux: value = TFHE.cmux(encryptedCondition, valueIfTrue, valueIfFalse)

Le contrat ERC20 confidentiel conforme

Maintenant que nous avons un registre d'identité et un contrat de régulation, nous pouvons enfin créer notre contrat de jeton conforme et respectueux de la vie privée. Ce contrat sera appelé CompliantERC20 et aura les caractéristiques clés suivantes :

• Le solde de l'utilisateur et le montant du transfert sont cryptés.
• La conformité est appliquée dans les transferts en appelant le contrat de régulation.
• La visibilité de certains soldes peut être accordée aux adresses blanches (par exemple, régulateurs)

Le contrat de régulation est invoqué via un simple appel. Cela implique que les utilisateurs doivent fournir l'accès au contrat ERC20 avant d'initier tout transfert; sinon, le transfert sera annulé.

Enfin, nous pouvons maintenant créer notre contrat ERC20 :

De la même manière que les utilisateurs accordent des autorisations aux protocoles DeFi pour dépenser leurs jetons, ils devront accorder une autorisation au contrat pour accéder aux identificateurs nécessaires par le contrat de régulation. Cela se fait via un appel à Identity.grantAccess(contractAddress, identifiers), qui peut être récupéré en appelant la méthode de vue ERC20.identifiers(). Cette liste provient directement du contrat ERC20Rules pour permettre la mise à jour des propriétés.

La conformité et la vie privée peuvent coexister!

Espérons que ce tutoriel vous a montré que la conformité n'est pas une chose difficile à construire si les bons outils sont disponibles. Alors que nous avons initialement construit le fhEVM pour permettre la confidentialité dans la blockchain, nous avons rapidement réalisé que cette technologie pourrait être utilisée pour la gestion de l'identité et donc la conformité programmable.

La conception proposée iciest loin d'être parfait, mais nous croyons qu'il peut facilement être amélioré et lancé comme un cas d'utilisation du monde réel, de sorte que la conformité ne soit plus synonyme de surveillance!

Liens supplémentaires

• Étoile Dépôt Github fhEVM de Zamapour approuver notre travail.
• Revoir Documentation fhEVM de Zama.
• Obtenez de l'aide sur notre canaux communautaires.
• Aidez à faire avancer l'espace FHE avec le programme de primes Zama : Créez un jeu sur chaîne qui garde les états privés cachés en utilisant la confidentialité programmable fhEVM de Zama(15,000€ en prix).

Avertissement：

1. Cet article est repris de [zamaTous les droits d'auteur appartiennent à l'auteur originalfhEVM]. Si des objections sont soulevées concernant cette réimpression, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.