Bitcoin, lancé il y a près de 14 ans, a révolutionné les transactions financières en éliminant les intermédiaires. L'avènement d'Ethereum et des contrats intelligents a encore accéléré cette tendance, éliminant les intermédiaires des produits financiers complexes tels que le trading, le prêt et les options. Cependant, le coût de l'élimination des intermédiaires a souvent été le sacrifice de la vie privée. Notre identité et nos transactions on-chain sont facilement suivies par les échanges centralisés, les rampes d'entrée/sortie, les sociétés d'analyse on-chain et de nombreuses autres entités. Cette transparence on-chain limite l'expansion du Web 3 à de nombreux cas d'utilisation tels que les paiements d'entreprise, le trading on-chain propriétaire et de nombreuses autres applications.

Ce problème n'est pas nouveau et de nombreux projets, par exemple, zCash, ont essayé de le résoudre depuis 2016 en introduisant des technologies telles que les Preuves de Connaissance Zéro (ZKPs). Depuis lors, la technologie ZK a progressé à un rythme insensé. De plus, de nombreuses autres technologies telles que le Cryptage Entièrement Homomorphique (FHE) et les Calculs Multi-parties Sécurisés (MPC) émergent pour aborder des scénarios plus sophistiqués d'utilisation de données privées on-chain, alias, État Privé.

Chez Alliance, nous croyons que la confidentialité on-chain permettra des cas d'utilisation qui n'étaient pas possibles auparavant et sera donc un thème central dans le Web 3 au cours des prochaines années. Si vous êtes un fondateur construisant une infrastructure de confidentialité ou des applications nécessitant un état privé, nous aimerions vous soutenir. Vous pouvez contacteret s'appliquent àAlliance.

Les différents types d'état privé

L'utilisation de données privées en chaîne signifie naturellement que ces données sont chiffrées. La confidentialité de ces données dépend de la possession de la clé de chiffrement/déchiffrement. Cette clé, c'est-à-dire la clé de confidentialité, est souvent différente de la clé privée habituelle, c'est-à-dire la clé pour signer les transactions. La première contrôle uniquement la confidentialité des données, la seconde contrôle la modification de ces données.

La nature de propriété de la clé de confidentialité conduit à différents types d'états privés. Le type d'état privé affecte significativement la façon dont cet état peut être représenté on-chain et la meilleure approche pour gérer cet état. En général, l'état privé peut être divisé en État privé personnel (EPP) et État privé partagé (ESP)

État privé personnel

Cela signifie que les données/l'état sont la propriété d'une seule entité et que seule cette entité peut les consulter ou les modifier. Cette entité peut également décider d'autoriser d'autres personnes à consulter les données, par exemple, en partageant une clé de visualisation pour l'ensemble ou une partie de ces données. Des exemples de cet état privé incluent :

• Solde de jetons privés
• Informations privées ou personnelles. cela inclut l'âge, la citoyenneté, le statut d'accréditation des investisseurs, le compte Twitter ou toute autre donnée Web 2 qui peut être utilisée dans le Web 3
• Historique des transactions privées

État privé partagé

Un état privé partagé (SPS) est une donnée privée que plusieurs personnes peuvent modifier/utiliser pour le calcul sans compromettre la confidentialité. Un SPS peut être un état accessible par n'importe qui et donc modifiable par n'importe quel utilisateur. Il peut s'agir de l'état d'un AMM de dark pool, de l'état d'un pool de prêt privé, etc. Un SPS peut également être limité à un petit groupe de participants pouvant accéder ou modifier les données. Des exemples de ce dernier cas incluent l'état d'un multi-joueur on-chain où seuls les joueurs actifs sont autorisés à modifier l'état. Cela peut également inclure des entrées privées dans un modèle d'IA on-chain, où seules quelques entités, par exemple l'opérateur de modèle, peuvent effectuer des calculs sur les données privées.

SPS est plus difficile à gérer que l'état privé personnel. Il est toujours plus difficile de raisonner sur le type de calcul qui peut être effectué sur SPS et de savoir si ce calcul peut divulguer des informations à son sujet. Par exemple, l'exécution d'un trade contre un AMM de dark-pool peut divulguer des informations sur la liquidité à l'intérieur du pool.

ZKPs, FHE, et MPC

Il existe différentes approches possibles pour gérer les états privés on-chain. Chaque approche est adaptée à un type particulier d'état privé et donc à un ensemble spécifique d'applications. Dans de nombreux cas, la création d'une application utile nécessite de combiner ces approches ensemble.

Preuves de connaissance zéro

La première approche qui a émergé pour gérer la confidentialité on-chain était d'utiliser des ZKPs. Cette approche est particulièrement adaptée aux données privées personnelles. Dans cette approche, le propriétaire des données peut simplement décrypter les données localement en utilisant sa clé de confidentialité, apporter les modifications nécessaires, chiffrer le résultat avec sa clé, et enfin générer un ZKP pour prouver au réseau que ses modifications de l'état privé sont valides.

Cela a rendu ZK particulièrement adapté aux réseaux de paiement, par exemple zCash, Iron Fish, et bien d'autres. Dans ces architectures, lorsque les utilisateurs effectuent des transactions en utilisant des actifs privés, ils effectuent tous les calculs localement, c'est-à-dire qu'ils dépensent des UTXO et en créent de nouveaux pour le destinataire, et modifient leurs soldes de jetons privés. Comme les calculs et la génération de preuves à divulgation nulle de connaissance se produisent localement sur l'appareil de l'utilisateur, la confidentialité des soldes et de l'historique des transactions est protégée. Les mineurs du réseau ne voient que les preuves à divulgation nulle de connaissance générées et les nouveaux UTXO chiffrés.

Malgré la simplicité des calculs nécessaires pour effectuer des paiements, l'expérience utilisateur des paiements privés était difficile en raison des longs temps de génération de ZKP. Cependant, avec des améliorations significatives dans les systèmes de preuve zk, le temps de génération de preuve pour des paiements simples est passé en dessous de 1 seconde sur du matériel grand public. Cela a également permis l'introduction de la programmabilité générale dans les systèmes basés sur zk.AztecetAleosont deux grands réseaux qui apportent une programmabilité générale aux chaînes zk. Aztec et Aleo ont quelques différences mais sont largement basés sur lemodèle ZEXE. Dans ce modèle, chaque application doit être implémentée comme un circuit zk. Cela a créé un besoin à la fois pour le réseau d'abstraire la complexité zk pour les développeurs d'applications et les utilisateurs. Cela a nécessité la création de langages de programmation de haut niveau, par exemple Noir (Aztec) et Leo (Aleo), qui peuvent convertir efficacement du code de haut niveau en circuits zk.

Par exemple, Aztec utilise Noir et son cadre de développement de contrat intelligent associé, Aztec.nr, pour décomposer chaque contrat intelligent en un ensemble de fonctions. Chaque fonction est implémentée sous la forme d'un circuit zk. Les utilisateurs peuvent effectuer des calculs généraux sur leurs données privées en téléchargeant les fonctions nécessaires et en effectuant les calculs localement sur leurs appareils. Les détails de l'exécution des contrats intelligents d'Aztec ont été discutés dans ce fil.

La mise en œuvre, comme Aztec, a considérablement amélioré la convivialité des systèmes zk en introduisant une programmabilité générale. Cependant, de tels systèmes présentent encore plusieurs défis :

1. Tout calcul sur l'état privé doit se faire côté client. Cela dégrade l'expérience utilisateur et nécessite que les utilisateurs disposent d'appareils capables d'utiliser le réseau.
2. L'approche zk n'est pas adaptée pour gérer l'état privé partagé. Par défaut, toutes les applications ont un état public. Cela rend difficile la construction d'applications telles que des jeux d'information incomplète et la DeFi privée.
3. Composabilité plus difficile, il n'est pas possible d'exécuter des transactions qui nécessitent de modifier plusieurs états privés car chaque état doit être calculé par un utilisateur séparé. Ces transactions doivent être décomposées en morceaux et chaque morceau doit être exécuté dans un bloc séparé.
4. Il existe également des défis en matière de découvrabilité des données privées. Si un utilisateur reçoit une transaction avec un état privé, il ne peut pas découvrir cet état à moins de télécharger tout l'état privé du réseau, d'essayer de décrypter chaque morceau en utilisant sa clé de confidentialité. Cela crée une expérience utilisateur difficile même pour effectuer des tâches simples comme interroger leur solde comme expliqué par cecifil.

Applications appropriées pour les systèmes basés sur zk

Les garanties de confidentialité robustes de zk le rendent adapté à un nombre considérable de cas d'utilisation

Médias sociaux anonymes

Certains personnages publics ne peuvent pas partager leurs vraies pensées et expériences de peur des réactions sociales et des annulations. Cela encourage un nouveau type de média social où les participants peuvent prouver en privé certains traits à propos d'eux-mêmes, par exemple, leur richesse on-chain ou le fait de posséder un NFT spécifique, et utiliser cette preuve pour poster de manière anonyme sans révéler leur véritable identité. Des exemples incluent Chansons de baleinesprototype par mon collègueDavid,

Identifiants privés sur la chaîne

Un exemple connexe consiste à permettre à des personnes ayant certaines qualifications de participer anonymement à un DAO ou de voter anonymement pour des sujets nécessitant une expertise spécifique. Un exemple de Web 3 de cela est HeyAnoun. Un domaine d'application plus vaste consiste à exploiter les justificatifs IRL, par exemple, la richesse IRL, les diplômes académiques, pour participer anonymement aux protocoles on-chain. L'intégration de justificatifs IRL privés on-chain peut permettre de multiples cas d'utilisation tels que le prêt DeFi non garanti, le KYC on-chain, ou le filtrage géographique. ZK est adapté à ces cas d'utilisation car il permet l'existence de clés de visualisation spécialisées pour des parties de l'état privé qui peuvent être utilisées dans des circonstances spécifiques, par exemple, le défaut de prêt.

Le principal défi de l'intégration des références IRL sur la chaîne est de garantir l'authenticité des références/données IRL. Certaines approches telles que zkEmailetTLSNotaryadresser ce problème en authentifiant le trafic web vers des domaines web spécifiques et en vérifiant que le domaine contient les données requises.

Facturation/ paiements d'entreprise

Un sous-ensemble important des paiements privés est le paiement d'entreprise. Les entreprises ne veulent souvent pas révéler leurs partenaires commerciaux/fournisseurs ou les modalités contractuelles de leurs accords. La transparence des paiements on-chain a limité l'adoption par les entreprises des paiements en stablecoin. Avec une confidentialité on-chain appropriée, adoption par les entreprises des paiements sur chaînepeut être accéléré en fonction de l'efficacité améliorée et de la rentabilité par rapport aux infrastructures bancaires existantes.

Approche FHE

Le cryptage pleinement homomorphique permet d'effectuer des calculs sur des données chiffrées et de générer des résultats chiffrés corrects sans décrypter les données pendant le calcul. Cela rend le FHE particulièrement adapté à la gestion des états privés partagés. Avec le FHE, il est possible de créer des applications sur chaîne qui ont un état privé, comme des pools AMM privés ou une urne électorale privée. L'état privé existe sur chaîne dans un format chiffré, ce qui permet à tout utilisateur d'effectuer des calculs sur ces données. L'incorporation du FHE sur chaîne peut permettre et simplifier de nombreux cas d'utilisation qui n'étaient pas possibles auparavant, tels que le vote privé et les jeux incomplets en information, par exemple le poker.

Avantages de la FHE

Un avantage significatif de FHE est d'améliorer la composition dans de multiples aspects.

1. Plusieurs transactions/utilisateurs peuvent modifier le même état privé au sein du même bloc. Par exemple, plusieurs échanges peuvent utiliser le même pool sombre.
2. Une seule transaction peut modifier plusieurs états privés. Par exemple, une transaction d'échange peut utiliser plusieurs pools dark AMM pour effectuer un échange.

Un autre avantage est une meilleure expérience utilisateur. En FHE, les calculs sur l'état privé sont effectués par les validateurs du réseau qui peuvent déployer un matériel spécialisé pour effectuer ces calculs plus rapidement.

Un troisième avantage de FHE est une meilleure expérience pour les développeurs. Bien que les développeurs doivent toujours mettre à jour leurs modèles mentaux pour gérer correctement l'état privé, la barrière est beaucoup plus basse que celle des systèmes zk. Tout d'abord, les systèmes FHE peuvent fonctionner avec le même modèle de compte que les chaînes de contrats intelligents utilisent. Deuxièmement, les opérations FHE peuvent être ajoutées aux implémentations VM existantes, permettant aux utilisateurs d'utiliser les mêmes cadres de développement, outils, portefeuilles et infrastructures auxquels ils sont habitués. C'est le cas pour le fhEVMimplémentation à partir deZamaqui ont simplement ajouté les variables cryptées et les opérations FHE en tant que précompilés. Contre-intuitivement, cet avantage est crucial pour la croissance des applications privées on-chain, les développeurs sont la clé pour créer des applications intéressantes qui attirent les utilisateurs. Une expérience de développeur sans couture peut attirer plus de développeurs vers l'espace FHE.

Limitations de FHE

Confiance en la confidentialité

Les chaînes FHE nécessitent des clés de chiffrement/déchiffrement mondiales pour l'ensemble de l'état privé. Ceci est essentiel pour atteindre la composabilité. En général, ces clés sont gérées par le groupe de validateurs afin de pouvoir déchiffrer les résultats des opérations FHE sur l'état privé. Cela signifie que le groupe de validateurs est aussi de confiancene pas violer la confidentialité des états privés existants.

Fuite potentielle de confidentialité
Effectuer de multiples calculs sur les données chiffrées peut compromettre la confidentialité. Par exemple, les transactions exécutées sur un pool AMM sombre peuvent révéler des informations sur la structure actuelle de la liquidité du pool.

Complexité computationnelle du calcul FHE

Même avec des mises en œuvre avancées, les opérations FHE sont souvent 1000x à 1 000 000x plus coûteuses en termes de calcul que les calculs réguliers. Cette complexité limite le débit possible des applications FHE on-chain. Les estimations actuelles du réseau Inco indiquent un débit compris entre 1 et 5 TPS pour les opérations FHE. Avec l'accélération GPU et FPGA, ce débit peut être accéléré de 10 à 50x.

Source : https://eprint.iacr.org/2021/1402.pdf

Applications appropriées pour les systèmes FHE

Les systèmes FHE sont particulièrement adaptés aux applications qui nécessitent un haut degré de componibilité

Jeux d'informations incomplets. Les exemples incluent ici des jeux de cartes, par exemple le poker, où l'état du jeu de cartes est accessible et peut être modifié par plusieurs joueurs.

Le vote privé, la FHE simplifie la mise en œuvre de scrutins secrets lorsque les votes peuvent modifier le décompte des votes sans connaître le résultat du vote précédent

AMM privé, la mise en œuvre d'AMM privés ou de pools DeFi privés en général est simplifiée en représentant l'état du pool comme une variable chiffrée.

Approche MPC

La informatique multiparti (MPC) est connue et populaire dans l'industrie de la crypto pour le cas d'utilisation spécifique de la garde d'actifs. Certaines des plus grandes entreprises de l'espace, par exemple, Fireblocksont construit des entreprises réussies autour de l'utilisation de MPC sécurisé pour la garde de la concurrence. En outre, de nombreux fournisseurs de portefeuille en tant que service, par exemple, Coinbase, 0xPass, utilisez MPC pour améliorer la sécurité du portefeuille et l'expérience utilisateur.

Cependant, le MPC peut être utilisé pour bien plus que sécuriser les clés privées. En général, le MPC résout le problème de l'exécution de calculs sur des entrées privées, c'est-à-dire des données, et ne révèle que la sortie des calculs sans compromettre la confidentialité des entrées. Dans le contexte spécifique de la garde d'actifs, les entrées privées sont les fragments de la clé privée. Les propriétaires de ces fragments collaborent pour effectuer un "calcul" sur ces entrées privées. Le calcul ici consiste à générer une signature de transaction. Les multiples parties génèrent et déchiffrent collectivement la signature sans qu'aucune d'entre elles n'ait accès aux entrées privées, c'est-à-dire à la clé privée.

De la même manière, le MPC permet tout type de calcul sur des données privées sans les révéler. Cela permet au MPC de gérer un état privé dans un contexte de blockchain. Un exemple en est l'entraînement décentralisé de l'IA sur des ensembles de données privées. Différents propriétaires de données et fournisseurs de calcul peuvent collaborer pour effectuer un entraînement IA basé sur le MPC sur les ensembles de données privées pour calculer les poids du modèle. La sortie du calcul, c'est-à-dire les poids, est décryptée par le groupe MPC après la phase d'entraînement pour créer le modèle IA complet.

De nombreuses implémentations de MPC offrent des garanties de confidentialité élevées pour la confidentialité des données, c'est-à-dire une minorité honnête, ce qui signifie qu'elles offrent des garanties de confidentialité similaires aux systèmes zk. Le MPC peut également ressembler à FHE car il permet d'effectuer des calculs sur un SPS, ce qui signifie qu'il peut permettre la composabilité. Cependant, par rapport à FHE, le MPC présente certaines limites.

1. Le calcul ne peut être effectué que par les entités qui font partie du groupe MPC. Personne en dehors de ce groupe ne peut effectuer de calculs sur les données
2. Pour garantir des minorités honnêtes, toutes les parties du MPC doivent coopérer pour effectuer le MPC. Cela signifie que le calcul peut être censuré par n'importe quel membre du groupe MPC. Cette limitation peut être assouplie en réduisant le seuil du MPC, c'est-à-dire le nombre d'entités nécessaires pour effectuer le calcul. Cependant, le prix à payer est que la confidentialité des données peut être compromise par une coordination entre un nombre plus restreint de participants.

Applications adaptées pour les systèmes MPC

Dark Pool CLOBs

Une des premières applications réelles de MPC dans DeFi est la mise en œuvre de Dark Pool CLOBs. Dans ce système, les traders peuvent passer des ordres limités ou au marché sans connaissance préalable de l'état du carnet de commandes. La correspondance des ordres se fait via MPC sur les données privées, c'est-à-dire le carnet de commandes existant.Finances Rebellesest l'une des entreprises construisant un tel système.

Inférence décentralisée de modèles d'IA propriétaires

Certaines applications, par exemple, les gestionnaires de stratégie basés sur l'IA DeFi ou Score de crédit Web 3, peut déployer MPC pour effectuer des inférences à l'aide de modèles propriétaires. Dans cette architecture, les poids du modèle d'IA sont privés. Les poids peuvent être partagés de manière sécurisée entre plusieurs nœuds de calcul de sorte que chacun n'ait qu'un sous-ensemble des poids du modèle. Les nœuds peuvent collaborer pour effectuer des inférences d'IA sur des événements mis à jour sur la chaîne pour prendre des décisions et soumettre des transactions qui exécutent la stratégie DeFi.

Formation de modèles d'IA ouverts à l'aide de données propriétaires

Un exemple courant ici est la formation de modèles de diagnostic médical en utilisant des dossiers de santé privés. Dans ce cas, les créateurs de modèles, les entreprises et les propriétaires de données, c'est-à-dire les patients, peuvent collaborer en utilisant MPC pour exécuter le processus de formation sur les données privées sans compromettre la confidentialité des données privées. Des réseaux tels que BittensoretNillionpeut activer de tels cas d'utilisation.

État privé partagé pseudo-autorisé

Avec une conception soignée, le MPC peut être utilisé pour gérer les SPS pseudo-autorisées. Par exemple, l'état d'un pool AMM sombre et le calcul sur cet état peuvent être construits comme un MPC entre un certain nombre d'entités. Les utilisateurs qui veulent interagir avec l'AMM doivent partager leurs transactions avec le groupe MPC pour effectuer les calculs en leur nom. L'avantage de cette approche est que chaque SPS peut avoir un ensemble différent de clés de confidentialité (par rapport aux clés globales dans le cas du FHE). Le risque de cette approche est la possibilité de censure par le groupe MPC. Cependant, avec une conception économique soignée, ce risque peut être atténué.

Concurrence ou Synergies

Les approches discutées de la gestion de l’État privé on-chain semblent compétitives à première vue. Cependant, si l’on met de côté les incitations financières des différentes équipes qui construisent ces réseaux, zk, FHE et MPC sont en réalité des technologies complémentaires.

D'une part, les systèmes zk offrent des garanties de confidentialité plus solides car les données "non chiffrées" ne quittent jamais l'appareil de l'utilisateur. De plus, il est impossible pour quiconque d'exécuter un calcul sur ces données sans la permission du propriétaire. Le prix de ces garanties de confidentialité renforcées est une moindre composabilité.

D'autre part, le MPC facilite une plus grande composabilité mais une moindre confidentialité. Le risque pour la confidentialité découle de la confiance accordée à une entité ou à un petit nombre d'entités possédant les clés de décryptage MPC globales. Malgré ce risque et parce que la composabilité est un ingrédient essentiel en cryptographie, le MPC peut permettre la confidentialité dans de nombreux cas d'utilisation importants comme DeFi.

L'implémentation de MPC offre un compromis unique entre les approches zk et FHE. MPC permet de calculer sur des données privées partagées. Ainsi, il offre plus de composabilité que les ZKPs. Cependant, le calcul sur cet état privé est limité à un petit ensemble de participants et n'est pas sans permission (contrairement à FHE).

Étant donné que les preuves à divulgation nulle de connaissance (ZKPs), le calcul multipartite sécurisé (MPC) et le chiffrement entièrement homomorphique (FHE) diffèrent dans leur rythme d'application, les applications pratiques nécessitent souvent de combiner ces technologies. Par exemple, Renegade Finance combine le MPC et les ZKPs pour permettre la construction d'un Dark Pool CLOB garantissant également que les participants disposent d'un capital suffisant pour couvrir leurs ordres cachés. De même, le jeu de poker on-chain, zkHoldem, combine les ZKPs et le FHE.

Nous nous attendons à ce que les réseaux axés sur la confidentialité combinent ces technologies sous-jacentes pour offrir aux développeurs de ces écosystèmes tous les outils dont ils ont besoin pour construire des applications de manière transparente. Par exemple, Aztec peut combiner une forme de MPC dans le réseau pour gérer l'état privé partagé. De même, Réseau Incopeut utiliser des preuves de connaissance nulle pour permettre des adresses privées et un historique de transactions privées.

Avec cette vision d'un avenir centré sur la confidentialité, Alliance a hâte de soutenir les fondateurs qui construisent cet avenir. Si vous construisez dans ce domaine, contacter et s'appliquer à Alliance.

Avertissement：

1. Cet article est repris de [ Alliance], Tous les droits d'auteur appartiennent à l'auteur original [Mohamed Fouda]. S’il y a des objections à cette réimpression, veuillez contacter le Gate Learné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 aucun 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 interdite.