Auteur: EQ Labs Source: equilibrium Traduction: Shanolva, Golden Finance

Notre série sur la vie privée, partie 1, présente la signification de la « vie privée », la différence entre la vie privée sur le réseau Blockchain et la vie privée sur le web2, ainsi que les difficultés de mise en œuvre de la vie privée sur le réseau Blockchain.

Le point principal de cet article est que si l'état final idéal est une infrastructure de confidentialité avec une programmabilité, capable de traiter des états privés partagés sans aucun point de défaillance unique, alors toutes les routes mènent à MPC. Nous examinerons également la maturité de MPC et ses hypothèses de confiance, mettrons l'accent sur les alternatives, les compromis et fournirons un aperçu de l'industrie.

Se libérer des entraves du passé et accueillir l'avenir

L'infrastructure de confidentialité actuellement présente dans le Bloc vise à traiter des cas d'utilisation très spécifiques, tels que les paiements privés ou les votes. Il s'agit d'une vision assez étroite, principalement reflétant les cas d'utilisation actuels du Bloc (transactions, transferts et spéculation). Comme l'a dit Tom Walpo - Les cryptoactifs souffrent du paradoxe de Fermi : 01928374656574839201

En plus d'accroître la liberté personnelle, nous pensons que la confidentialité est une condition préalable à l'élargissement de l'espace de conception du Bloc, au-delà des métadonnées spéculatives actuelles. De nombreuses applications nécessitent un certain état privé et/ou une logique cachée pour fonctionner correctement :

• État masqué : la plupart des cas d'utilisation financiers nécessitent (au minimum) de garder confidentiels les informations vis-à-vis des autres utilisateurs, et sans certains états masqués, le plaisir de nombreux jeux serait grandement réduit (par exemple, si chaque personne à la table de poker pouvait voir les cartes des autres).
• Hidden Logic : Certains cas d'utilisation nécessitent de masquer certaines logiques tout en permettant à d'autres personnes d'utiliser l'application, par exemple les stratégies de transaction 01928374656574839201, moteur adapté, off-chain, etc.

L'analyse empirique (provenant de web2 et web3) montre que la plupart des utilisateurs ne sont pas prêts à payer des frais supplémentaires ou à sauter des étapes supplémentaires pour améliorer la confidentialité, et nous sommes d'accord sur le fait que la confidentialité elle-même n'est pas un argument de vente. Cependant, elle permet bel et bien de nouveaux cas d'utilisation (espérons-le) plus significatifs de se développer sur la blockchain - nous échappons ainsi au paradoxe de Fermi.

Les technologies de renforcement de la confidentialité (PET) et les solutions cryptographiques modernes (« Programmabilité cryptographique ») sont les modules de base pour réaliser cette vision (pour plus d'informations sur les différentes solutions disponibles et leurs compromis, veuillez vous référer à l'annexe).

Trois hypothèses qui influencent notre point de vue

Notre vision du développement de l'infrastructure de confidentialité de la blockchain est basée sur trois hypothèses clés :

1. La technologie de chiffrement sera retirée des mains des développeurs d’applications : La plupart des développeurs d’applications ne veulent pas (ou ne savent pas comment s’y prendre) de la technologie de chiffrement nécessaire pour gérer la vie privée. Il n’est pas raisonnable de s’attendre à ce qu’ils mettent en œuvre leur propre technologie de chiffrement et construisent des chaînes d’applications privées* (par exemple, Zcash ou Namada) ou des applications privées sur des chaînes publiques (par exemple, Tornado Cash). C’est tout simplement trop complexe et trop lourd, et cela limite actuellement l’espace de conception pour la plupart des développeurs (incapables de créer des applications qui nécessitent une certaine confidentialité). Par conséquent, nous pensons qu’il est important d’abstraire la complexité de la gestion de la partie chiffrement des mains des développeurs d’applications. Les deux approches ici sont l’infrastructure de confidentialité Programmabilité (L1/L2 privée partagée) ou le « Secret-as-a-Service », qui permet d’externaliser l’informatique confidentielle.
2. De nombreux cas d'utilisation (peut-être plus nombreux que ce que nous imaginons) nécessitent le partage d'états privés : comme mentionné précédemment, de nombreuses applications nécessitent certains états et/ou logiques cachés pour fonctionner correctement. Le partage d'états privés est un sous-ensemble de cela, où plusieurs parties effectuent des calculs sur le même état privé. Bien que nous puissions faire confiance à une entité centralisée pour le faire pour nous et en rester là, idéalement, nous aimerions le faire de manière à minimiser la confiance, afin d'éviter les défaillances ponctuelles. Se reposer uniquement sur les Arguments succincts et non interactifs de la connaissance (zk-SNARKs) ne permet pas d'atteindre cet objectif - nous devons utiliser d'autres outils tels que l'environnement d'exécution sécurisé (TEE), le chiffrement homomorphique intégral (FHE) et/ou les calculs multipartites (MPC).
3. Un ensemble de bouclage plus important peut protéger au maximum la vie privée : la plupart des informations sont susceptibles de fuite lorsqu'elles entrent ou sortent de l'ensemble de bouclage, il convient donc de réduire au maximum ce scénario. La création de plusieurs applications privées sur la même chaîne de blocs peut renforcer la protection de la vie privée en augmentant le nombre d'utilisateurs et de transactions au sein du même ensemble de bouclage.

La fin de l'infrastructure de confidentialité

En tenant compte des hypothèses susmentionnées, quel est l'objectif final de l'infrastructure de confidentialité des blocs? Y a-t-il une méthode qui convient à toutes les applications? Existe-t-il une technologie d'amélioration de la confidentialité qui peut gouverner toutes les applications?

Pas tout à fait. Tout cela implique des compromis différents, nous les avons vus se combiner de différentes manières. Globalement, nous avons identifié 11 méthodes différentes.

Actuellement, les deux méthodes les plus populaires pour construire des infrastructures de confidentialité dans la blockchain sont l'utilisation de ZKP ou de FHE. Cependant, les deux présentent des défauts fondamentaux :

• Les protocoles de confidentialité basés sur ZK et avec une preuve côté client peuvent offrir une protection de la vie privée puissante, mais ils ne permettent pas de calculer plus longuement le même état privé. Cela limite la capacité d'expression, c'est-à-dire les types d'applications que les développeurs peuvent construire.
• FHE prend en charge le calcul des données de chiffrement et de l'état privé partagé, mais soulève la question de qui possède la Clé secrète de déchiffrement. Cela limite la force de la protection de la vie privée et la confiance que nous pouvons avoir en elle aujourd'hui et demain.

Si l'état final idéal est d'avoir une infrastructure de confidentialité avec la Programmabilité, capable de traiter des états privés partagés sans aucun point de défaillance unique, alors deux voies peuvent mener à MPC :

Veuillez noter que bien que ces deux méthodes finissent par converger, les utilisations de MPC sont différentes :

• Réseau ZKP : MPC augmente la capacité d'expression en réalisant des calculs partagés sur des états privés.
• Réseau FHE : MPC améliore la sécurité et renforce la confidentialité en distribuant le secret Clé secrète aux membres du comité MPC (plutôt qu'à des tiers individuels).

Bien que la discussion se tourne vers des points de vue plus détaillés, les garanties sous-jacentes à ces différentes approches n'ont pas encore été pleinement explorées. Étant donné que notre hypothèse de confiance se réduit à l'hypothèse du MPC, trois questions clés doivent être posées :

1. Quelle est la force de la protection de la vie privée que le protocole MPC peut fournir dans la chaîne de blocs ?
2. La technologie est-elle suffisamment mature ? Sinon, quel est le goulot d'étranglement ?
3. En considérant la force de garantie et les coûts qu'elle entraîne, est-ce qu'il est plus significatif que les autres méthodes ?

Permettez-nous de répondre plus en détail à ces questions.

Utilisation de l'analyse MPC pour évaluer les risques et les points faibles

Chaque fois qu'une solution utilise FHE, les gens se demandent toujours : "Qui possède la Clé secrète ?". Si la réponse est "le réseau", la question suivante est : "Quelles entités réelles composent ce réseau ?". La question ultérieure est liée à tous les cas d'utilisation qui dépendent d'une manière ou d'une autre de MPC.

Source: Speech by Zama on ETH CC

Le principal risque du MPC est la collusion, c'est-à-dire qu'il y a suffisamment de parties prenantes malveillantes qui collaborent pour décrypter les données ou voler des calculs. La collusion peut être réalisée off-chain et ne sera révélée que lorsque les parties malveillantes prennent des mesures évidentes (chantage, création de jetons Jeton à partir de rien, etc.). Il ne fait aucun doute que cela a un impact majeur sur la confidentialité que le système peut offrir. Le risque de collusion dépend de :

• À quel point ce protocole peut-il résister à des parties malveillantes ?
• De quels côtés se compose le réseau ? Quelle est leur crédibilité ?
• Le nombre et la répartition des différentes parties prenantes du réseau - existe-t-il des vecteurs d'attaque courants ?
• Le réseau est-il sans licence ou nécessite-t-il une licence (bénéfices économiques et réputation / bases juridiques)?
• Quelle est la punition pour un comportement malveillant ? Est-ce que la collusion et la tricherie sont le résultat optimal en théorie ?

1. Quelle est la force de protection de la vie privée offerte par le protocole MPC dans la chaîne de blocs ?

TLDR: Pas aussi puissant que nous l'espérions, mais plus puissant que de compter sur un tiers centralisé.

Le seuil requis pour le déchiffrement dépend du schéma MPC choisi, en grande partie un compromis entre la vivacité* (« livraison de sortie garantie »)* et la sécurité. Vous pouvez prendre un schéma N/N très sécurisé, mais dès qu’un nœud est hors ligne, il plante. D’autre part, le schéma N/2 ou N/3 est plus robuste mais présente un risque de collusion plus élevé.

Les deux conditions à équilibrer sont :

1. Les informations confidentielles ne seront jamais divulguées (par exemple, décrypter la Clé secrète)
2. Les informations confidentielles ne disparaîtront jamais (même si 1/3 des participants partent soudainement).

Les plans choisis varient en fonction de la mise en œuvre. Par exemple, l'objectif de Zama est de N/3, tandis que Arcium met actuellement en œuvre un plan N/N, mais prendra également en charge ultérieurement des plans avec une garantie d'activité plus élevée (et des hypothèses de confiance plus importantes).

À ce point de compromis, une solution de compromis est d'adopter une solution mixte :

• Le * comité de confiance élevée * traite avec un seuil de N/3, par exemple Clé secrète.
• Le comité de calcul est tournant, par exemple, avec N-1 seuils (ou plusieurs comités de calcul différents avec des caractéristiques différentes pour que les utilisateurs choisissent).

Bien que cela soit théoriquement attrayant, cela introduit également une complexité supplémentaire, par exemple comment le comité de calcul interagit avec le comité de haute confiance.

Un autre moyen de renforcer la sécurité est d'exécuter le MPC dans un matériel de confiance pour partager et stocker la Clé secrète dans une zone sécurisée. Cela rend l'extraction ou l'utilisation de la Clé secrète pour des opérations autres que la définition du protocole plus difficile. Au moins Zama et Arcium explorent l'angle TEE.

Les risques plus subtils incluent des situations marginales telles que l'ingénierie sociale, par exemple, toutes les entreprises du cluster MPC emploient un ingénieur principal depuis plus de 10 à 15 ans.

2. Est-ce que la technologie est suffisamment mature? Si elle ne l'est pas, quel est le goulot d'étranglement?

Du point de vue des performances, MPC est confronté au défi clé de l'overhead de communication. Il hausse avec la complexité des calculs et l'augmentation du nombre de Nœuds dans le réseau (nécessitant plus de communications aller-retour). Pour les cas d'utilisation de la Bloc, cela entraînera deux impacts concrets :

1. Petit ensemble d'opérateurs : Pour contrôler les coûts de communication, la plupart des protocoles existants sont actuellement limités à un petit ensemble d'opérateurs. Par exemple, le réseau de déchiffrement de Zama autorise actuellement au maximum 4 nœuds (bien qu'ils prévoient de l'étendre à 16). Selon le benchmark initial publié par Zama pour son réseau de déchiffrement (TKMS), même avec un cluster de seulement 4 nœuds, le déchiffrement prend de 0,5 à 1 seconde (le processus complet e2e prend plus de temps). Un autre exemple est le MPC mis en œuvre par Taceo pour la base de données d'iris de Worldcoin, qui compte 3 parties (en supposant que 2/3 des parties soient honnêtes).

Source: Speech by Zama on ETH CC 2. 3. Ensemble d'opérateurs sous licence: Dans la plupart des cas, l'ensemble d'opérateurs est autorisé. Cela signifie que nous nous appuyons sur la réputation et les contrats légaux plutôt que sur la sécurité économique ou le chiffrement. Le principal défi d'un ensemble d'opérateurs sans licence est de ne pas savoir si les gens sont en collusion hors chaîne. De plus, il faut régulièrement guider ou redistribuer les parts de clés pour permettre aux nœuds d'entrer ou de sortir dynamiquement du réseau. Bien que l'ensemble d'opérateurs sans licence soit l'objectif ultime et que des recherches soient en cours sur la façon d'étendre le mécanisme de preuve d'enjeu (PoS) pour atteindre le MPC de seuil (par exemple, Zama), la voie sous licence semble être la meilleure direction à suivre pour l'instant.

Méthode de remplacement

Un ensemble complet de confidentialité comprend :

• FHE est utilisé pour la computation privée déléguée
• ZKP est utilisé pour vérifier si le calcul FHE est correctement exécuté
• MPC for Threshold Decryption
• Chaque Nœud MPC fonctionne dans un environnement TEE pour renforcer la sécurité

C'est compliqué, avec beaucoup de scénarios extrêmes non explorés introduits, ce qui entraîne de gros coûts et peut être difficile à réaliser dans les années à venir. Un autre risque est que les gens puissent se sentir faussement en sécurité en superposant plusieurs concepts complexes. Plus nous ajoutons de complexité et supposons la confiance, plus il est difficile de déduire la sécurité de la solution globale.

Vaut-il la peine? Peut-être que cela vaut la peine, mais il vaut également la peine d'explorer d'autres méthodes qui pourraient offrir une efficacité de calcul considérablement meilleure, avec seulement une légère diminution de la garantie de confidentialité. Comme l'a souligné Lyron de Seismic, nous devrions nous concentrer sur des solutions simples qui répondent à nos normes de niveau de confidentialité requis et de compromis acceptables, plutôt que de les concevoir excessivement pour cette seule raison.

1. Utiliser directement MPC pour calculs généraux

Si ZK et FHE finissent par revenir à l'hypothèse de confiance de MPC, pourquoi ne pas simplement utiliser MPC pour les calculs ? C'est une question légitime, et c'est aussi ce que des équipes comme Arcium, SodaLabs (utilisation de COTI v2), Taceo et Nillion tentent de faire. Veuillez noter que le MPC se présente sous plusieurs formes, mais parmi les trois principaux méthodes, nous faisons référence ici au protocole basé sur le partage de secrets et les circuits garbled (GC), et non au protocole basé sur FHE pour le déchiffrement utilisant le MPC.

Bien que MPC ait été utilisé pour des signatures distribuées et des calculs simples tels que Portefeuille plus sécurisés, le principal défi de l'utilisation de MPC pour des calculs plus généraux est le coût de communication (qui augmente avec la complexité des calculs et le nombre de Nœud impliqués).

Il existe plusieurs façons de réduire les dépenses, telles que le traitement préalable hors ligne (c'est-à-dire la partie la plus coûteuse du protocole) - Arcium et SodaLabs explorent tous deux ce point. Ensuite, effectuez des calculs en ligne, ce qui consommera certaines données générées lors de la phase hors ligne. Cela réduit considérablement l'ensemble des coûts de communication.

Le tableau ci-dessous de SodaLabs montre le Benchmark initial en microsecondes nécessaire pour exécuter 1 000 fois différentes codes d'opération dans son gcEVM. Bien que ce soit un pas dans la bonne direction, il reste beaucoup de travail à faire pour améliorer l'efficacité et étendre l'ensemble d'opérateurs à plusieurs nœuds.

Source: SodaLabs

Les avantages de la méthode basée sur ZK sont que vous n'utilisez MPC que pour les cas d'utilisation nécessitant des calculs dans un état privé partagé. La concurrence entre FHE et MPC est plus directe et dépend fortement de l'accélération matérielle.

2. Environnement d'exécution de confiance

Récemment, l'intérêt pour le TEE a été ravivé, il peut être utilisé seul (sur une blockchain privée basée sur le TEE ou un coprocesseur), ou combiné avec d'autres PET (comme des solutions basées sur ZK) (pour effectuer des calculs partageant l'état privé uniquement en utilisant le TEE).

Bien que TEE soit plus mature à certains égards et introduise moins de surcoûts de performance, ils ne sont pas sans défauts. Premièrement, TEE a des hypothèses de confiance différentes (1/N) et offre une solution basée sur le matériel plutôt que sur le logiciel. La critique courante tourne autour des failles passées de SGX, mais il est important de noter que TEE ≠ Intel SGX. TEE nécessite également de faire confiance au fournisseur de matériel, et le matériel est coûteux (la plupart des gens ne peuvent se le permettre). Une solution pour traiter le risque d'attaque physique pourrait être d'exécuter TEE dans l'espace pour gérer les tâches critiques.

Dans l'ensemble, TEE semble plus adapté aux preuves ou aux cas d'utilisation ne nécessitant qu'une confidentialité à court terme (décryptage de seuil, livres de commande obscur, etc.). Pour une confidentialité permanente ou à long terme, la sécurité semble moins attrayante.

3. Méthodes de protection de la vie privée des DAC privés et autres dépendant de tiers de confiance

L'intermédiaire peut fournir la confidentialité pour empêcher l'accès des autres utilisateurs, mais la garantie de confidentialité repose entièrement sur la confiance envers les tiers (point de défaillance unique). Bien qu'il soit similaire à la "confidentialité web2" (empêchant la confidentialité des autres utilisateurs), il peut être renforcé par des garanties supplémentaires (chiffrement ou économie) et permettre la vérification d'une exécution correcte.

Le comité de disponibilité des données privées (DAC) en est un exemple ; les membres du DAC stockent les données hors chaîne, et les utilisateurs ont confiance en eux pour stocker correctement les données et effectuer les mises à jour de l'état. Une autre forme est le séquenceur agréé proposé par Tom Walpo.

Bien que cette approche fasse de grands compromis en termes de protection de la vie privée, elle peut être la seule solution de remplacement viable pour les applications à faible valeur et haute performance en termes de coût et de performance (du moins pour le moment). Par exemple, le protocole Lens prévoit d'utiliser un DAC privé pour réaliser un flux d'informations privées. Pour des cas d'utilisation tels que les réseaux sociaux hors chaîne, il peut être raisonnable de faire un compromis entre la confidentialité et le coût/performance (en tenant compte du coût et des dépenses des solutions de remplacement).

4. Adresse invisible

L'Adresse invisible peut offrir des garanties de confidentialité similaires à la création d'une nouvelle Adresse pour chaque transaction, mais ce processus est effectué automatiquement en arrière-plan et n'est pas divulgué aux utilisateurs. Pour plus d'informations, veuillez consulter cet aperçu de Vitalik ou cet article approfondi sur les différentes approches. Les principaux acteurs de ce domaine comprennent Umbra et Fluidkey.

Bien que les adresses invisibles fournissent une solution relativement simple, leur principal inconvénient est qu'elles ne peuvent garantir la confidentialité que des transactions (paiements et transferts), et non des calculs généraux. Cela les distingue des trois autres solutions mentionnées ci-dessus.

De plus, l'anonymat fourni par l'Adresse cachée n'est pas aussi puissant que d'autres solutions de remplacement. L'anonymat peut être brisé par une simple analyse de regroupement, en particulier lorsque les transferts entrants et sortants ne se situent pas dans une plage similaire (par exemple, recevoir 10 000 dollars, mais dépenser en moyenne entre 10 et 100 dollars par jour). Un autre défi pour l'Adresse cachée est la mise à jour de la Clé secrète, qui doit maintenant être effectuée individuellement pour chaque portefeuille (le stockage consolidé de la Clé secrète peut aider à résoudre ce problème). En termes d'expérience utilisateur, si le compte n'a pas de Jeton de frais (comme ETH), le protocole Adresse cachée nécessite toujours une abstraction de compte ou que le payeur paye les frais.

Les risques auxquels notre argumentaire est confronté

Compte tenu de la rapidité du développement et de l'incertitude générale des solutions technologiques différentes, nous pensons que l'argument en faveur du MPC en tant que solution finale présente certains risques. Il est possible que nous n'ayons finalement pas besoin d'une forme quelconque de MPC, principalement pour les raisons suivantes :

1. Le partage de l'état privé n'est pas aussi important que nous le pensons : dans ce cas, l'infrastructure basée sur ZK est plus susceptible de l'emporter, car elle offre une meilleure garantie de confidentialité et des coûts plus faibles que le FHE. Il existe déjà quelques cas d'utilisation qui montrent que les systèmes basés sur ZK fonctionnent bien dans des cas isolés, comme le protocole de paiement privé Payy.
2. Les compromis de performance ne valent pas les avantages de la confidentialité : certaines personnes pourraient dire que l'hypothèse de confiance d'un réseau MPC avec 2 à 3 parties autorisées n'est guère différente de celle d'un participant centralisé unique, et que les coûts/dépenses supplémentaires ne sont pas justifiés. Pour de nombreuses applications, en particulier celles de faible valeur ou sensibles aux coûts (comme les applications sociales ou les jeux), cela peut être vrai. Cependant, il existe également de nombreux cas d'utilisation à forte valeur ajoutée où la collaboration est actuellement très coûteuse (ou impossible) en raison de problèmes juridiques ou de frictions de coordination. C'est là que les solutions MPC et basées sur le FHE peuvent briller.
3. La spécialisation l'emporte sur la conception générale : il est très difficile de construire une nouvelle chaîne et de guider la communauté des utilisateurs et des développeurs. Par conséquent, il peut être difficile de suivre les infrastructures de confidentialité générales (L1/L2). Un autre problème concerne la spécialisation ; il est difficile de concevoir un protocole unique qui couvre tout l'espace des compromis. Dans ce monde, les solutions qui offrent la confidentialité aux écosystèmes existants (confidentialité en tant que service) ou aux cas d'utilisation spécifiques (comme les paiements) prendront le dessus. Cependant, nous sommes sceptiques à l'égard de ce dernier, car il apporte de la complexité aux développeurs d'applications, qui doivent mettre en œuvre eux-mêmes certaines techniques de chiffrement (au lieu de les abstraire).
4. La réglementation continue de freiner les expérimentations de solutions de confidentialité : c'est un risque pour quiconque construit une infrastructure de confidentialité et des applications avec certaines garanties de confidentialité. Les cas d'utilisation non financiers sont moins exposés aux risques réglementaires, mais il est difficile (voire impossible) de contrôler ce qui est construit sur une infrastructure de confidentialité sans permission. Il est fort probable que nous devrons résoudre les problèmes techniques avant de résoudre les problèmes réglementaires.
5. La surcharge des scénarios basés sur MPC et FHE est encore trop élevée pour la plupart des cas d’utilisation : alors que MPC est principalement affecté par la surcharge de communication, l’équipe FHE s’appuie fortement sur l’accélération matérielle pour améliorer ses performances. Cependant, si nous pouvons extrapoler le développement de matériel spécialisé du côté de ZK, il faudra beaucoup plus de temps que la plupart des gens ne le pensent avant d’obtenir du matériel FHE prêt pour la production. Les équipes travaillant sur l’accélération matérielle FHE comprennent Optalysys, fhela et Niobium.

Résumé

Au final, la force de la chaîne dépend de son maillon le plus faible. Dans le cas de l'infrastructure de confidentialité programmable, si nous voulons qu'elle puisse gérer des états privés partagés sans point de défaillance unique, la garantie de confiance se résume à la garantie de MPC.

Bien que cet article semble critiquer le MPC, ce n'est pas le cas en réalité. Le MPC a considérablement amélioré la situation actuelle qui dépend fortement des tiers centralisés. Nous pensons que le principal problème réside dans la fausse confiance qui règne dans toute l'industrie, et que ce problème est dissimulé. Au contraire, nous devrions affronter les problèmes et nous concentrer sur l'évaluation des risques potentiels.

Cependant, tous les problèmes ne nécessitent pas l'utilisation des mêmes outils pour les résoudre. Bien que nous considérions le MPC comme l'objectif final, d'autres méthodes sont également des choix viables tant que le coût des solutions basées sur le MPC reste élevé. Il est toujours utile de considérer quelles méthodes conviennent le mieux aux besoins/caractéristiques spécifiques du problème que nous essayons de résoudre, ainsi que les compromis que nous sommes prêts à faire.

Même si vous avez le meilleur marteau du monde, tout n'est pas forcément un clou.