Toutes les routes mènent à MPC?Explorez la fin de l’infrastructure de confidentialité

Auteur: EQ Labs Source: Traduction d’équilibre: Shan Oppa, Vision de Bitchain

La partie 1 de notre série de confidentialité couvre ce que signifie la «confidentialité», comment la confidentialité dans un réseau de blockchain diffère de la confidentialité de Web2, et pourquoi la confidentialité est difficile à réaliser dans la blockchain.

Le point principal de cet article est que si l’état final idéal est d’avoir une infrastructure de confidentialité programmable qui peut gérer un état privé partagé sans aucun point d’échec, alors toutes les routes mènent à MPC.Nous explorerons également la maturité du MPC et ses hypothèses de confiance, mettrons l’accent sur les approches alternatives, comparer les compromis et fournir un aperçu de l’industrie.

Débarrassez-vous des chaînes du passé et accueillez le futur

L’infrastructure de confidentialité existante dans la blockchain est conçue pour gérer des cas d’utilisation très spécifiques tels que les paiements privés ou le vote.Il s’agit d’une vue assez étroite, reflétant principalement l’objectif actuel de la blockchain (transactions, transferts et spéculation).Comme l’a dit Tom Walpo – les crypto-monnaies souffrent de Fermi Paradox:

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

• Cacher l’état: La grande majorité des cas d’utilisation financière nécessitent (au moins) de garder confidentiels pour les autres utilisateurs, et sans un état caché, de nombreux jeux multijoueurs seront beaucoup moins amusants (par exemple, si tout le monde sur la table de poker peut voir les cartes de l’autre).

• Masquer la logique: Certains cas d’utilisation nécessitent une certaine logique pour être cachée tout en permettant à d’autres d’utiliser l’application, telles que les moteurs de correspondance, les stratégies de trading en chaîne, etc.

L’analyse empirique (de Web2 et Web3) montre que la plupart des utilisateurs hésitent à payer des frais supplémentaires ou à sauter des liens supplémentaires pour augmenter la confidentialité, et nous convenons également que la confidentialité elle-même n’est pas un argument de vente.Cependant, cela permet à des cas d’utilisation nouveaux et (espérons-le) plus significatifs d’exister au-dessus de la blockchain – nous débarrasser du paradoxe de Fermi.

Technologie d’amélioration de la confidentialité (TEP) et solutions de mot de passe modernes(« Mot de passe programmable»)C’est le bloc de construction de base pour réaliser cette vision(Pour plus d’informations sur les différentes solutions disponibles et leurs compromis, voirappendice).

Trois hypothèses qui influencent notre point de vue

Trois hypothèses clés déterminent notre point de vue sur le développement de l’infrastructure de confidentialité de la blockchain:

1. La technologie de chiffrement sera abstraite des mains des développeurs d’applications: la plupart des développeurs d’applications ne veulent pas (ou ne savent pas comment gérer) la technologie de chiffrement dont ils ont besoin pour gérer la confidentialité.J’espère qu’ils mettent en œuvre leur propre technologie de chiffrement et créent des chaînes spécifiques aux applications privées(Par exempleZcashouNamada) ou dans la chaîne publique(par exemple, Tornado Cash)Une demande privée ci-dessus est déraisonnable.Ceci est trop complexe et des frais généraux, et limite actuellement l’espace de conception de la plupart des développeurs (ne peut pas créer d’applications qui nécessitent une certaine assurance de confidentialité).Par conséquent, nous pensons que la complexité de la gestion de la partie de chiffrement doit être abstraite des mains des développeurs d’applications.Les deux méthodes ici sont une infrastructure de confidentialité programmable (partagée privée L1 / L2) ou« Confidentiel comme service », ce dernier permet d’externaliser des calculs confidentiels.

2. De nombreux cas d’utilisation (probablement plus que ce que nous pensions) nécessitent du partage de l’état privé: comme mentionné précédemment, de nombreuses applications nécessitent un état caché et / ou une logique pour fonctionner correctement.L’état privé partagé en est un sous-ensemble, dans lequel plusieurs parties calculent le même état privé.Bien que nous puissions faire confiance à une partie centralisée pour le faire pour nous et nous arrêter là, nous voulons idéalement le faire avec une minimisation de confiance pour éviter un seul point d’échec.Ce n’est pas possible avec la preuve de connaissances zéro (ZKP) seul – nous devons tirer parti d’autres outils tels que l’environnement d’exécution de confiance (TEE), le cryptage entièrement homomorphe (FHE) et / ou l’informatique multipartite (MPC).

3. Les ensembles bloqués plus grands maximisent la confidentialité: la plupart des informations sont divulguées lors de la saisie ou de la sortie des ensembles bloqués, nous devons donc minimiser cela.La création de plusieurs applications privées sur la même blockchain peut aider à renforcer la confidentialité en augmentant le nombre d’utilisateurs et les transactions dans le même ensemble bloqué.

La fin de l’infrastructure de confidentialité

Compte tenu des hypothèses ci-dessus, quel est l’objectif ultime de l’infrastructure de confidentialité de la blockchain?Existe-t-il un moyen de s’adapter à toutes les applications?Existe-t-il une technologie d’amélioration de la confidentialité qui peut dominer toutes les applications?



Pas exactement.Tous ces éléments ont des compromis différents et nous les avons vus se réunir de diverses manières.Dans l’ensemble, nous avons identifié 11 approches différentes.

Actuellement, les deux façons les plus populaires de construire une infrastructure de confidentialité dans la blockchain consiste à tirer parti du ZKP ou du FHE.Cependant, les deux ont des défauts fondamentaux:

• Un protocole de confidentialité basé sur ZK et avec la preuve du client peut fournir de solides garanties de confidentialité, mais ne permet pas à plusieurs parties de calculer le même état privé.Cela limite la puissance expressive, c’est-à-dire quels types d’applications qu’un développeur peut créer.

• FHE prend en charge les données cryptées de l’informatique et un état privé partagé, mais qui l’a fait?avoirLe problème avec cet état est qui possède la clé de décryptage.Cela limite la force de la protection de la vie privée et la mesure dans laquelle nous pouvons croire que la vie privée d’aujourd’hui le restera demain.

Si l’état final idéal est d’avoir une infrastructure de confidentialité programmable, l’état privé partagé peut être manipuléSans aucun point d’échec, alors les deux chemins peuvent conduire à MPC:



Notez que bien que ces deux méthodes auront finalement tendance à se mélanger, MPC utilise différemment:

• Réseau ZKP: MPC augmente la capacité d’expression en mettant en œuvre le calcul de l’état privé partagé.

• Réseau FHE: MPC améliore la sécurité et renforce la confidentialité en distribuant des clés de décryptage au comité MPC (plutôt qu’un seul tiers).

Alors que la discussion a commencé à se tourner vers un point de vue plus nuancé, les assurances derrière ces différentes approches étaient encore sous-explorées.Étant donné que notre hypothèse de confiance se résume à l’hypothèse du MPC, les trois questions clés qui doivent être posées sont:

1. Quelle est la forte garantie de la confidentialité que le protocole MPC peut fournir dans la blockchain?

2. La technologie est-elle suffisante?Si ce n’est pas suffisant, quel est le goulot d’étranglement?

3. Cela a-t-il du sens par rapport à d’autres méthodes compte tenu de la force de la garantie et de ses frais généraux?

Répondons à ces questions plus en détail.

Utilisez MPC pour analyser les risques et les faiblesses

Chaque fois que la solution utilise les gens, les gens doivent toujours demander: «Qui a la clé de décryptage?».Si la réponse est « réseau », alors la question suivante est: « Quelles entités réelles constituent ce réseau? ».Cette dernière question est liée à tous les cas d’utilisation qui dépendent du MPC sous une forme ou d’une autre.



Source:Le discours de Zama à ETH CC

Le principal risque de MPC est la collusion, c’est-à-dire qu’il y a suffisamment de parties impliquées dans la collusion malicieusement pour décrypter les données ou mal adapter des calculs.La collusion peut être contenue hors de la chaîne et ne sera révélée que si le parti malveillant prend une action évidente (ransformation, frappes de fraude à la fin de l’air, etc.).Inutile de dire que cela a un impact significatif sur les garanties de confidentialité que le système peut fournir.Le risque de collusion dépend de:

• Combien de parties malveillantes que cet accord peut-il supporter?

• Quels sont les réseaux?À quel point sont-ils crédibles?

• Le nombre de différentes parties impliquées dans le réseau et leur distribution – Y a-t-il des vecteurs d’attaque communs?

• Le réseau est-il sans licence ou ayant besoin de licence (intérêts économiques et réputation / base juridique)?

• Quelles sont les punitions pour un comportement malveillant?Le jeu de collusion est-il théoriquement le résultat optimal?

1. Quelle est la force de la garantie de confidentialité que le protocole MPC peut fournir dans la blockchain?

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

Le seuil requis pour le décryptage dépend du schéma MPC sélectionné – en grande partie le niveau d’activité(« Livraison de sortie garantie »)et compromis de sécurité.Vous pouvez prendre un schéma N / N très sécurisé, mais il se bloquera tant qu’il y a un nœud hors ligne.D’un autre côté, le schéma N / 2 ou N / 3 est plus robuste, mais le risque de complot est plus élevé.

Deux conditions qui doivent être équilibrées sont:

1. Les informations secrètes ne sont jamais divulguées (comme les clés de décryptage)

2. Les informations secrètes ne disparaissent jamais (même si 1/3 des participants partent soudainement).

Le schéma sélectionné varie selon la mise en œuvre.Par exemple, Zama vise à être N / 3, tandis que Arcium met actuellement en œuvre un schéma N / N, mais soutiendra également un schéma avec une assurance d’activité plus élevée (et de plus grandes hypothèses de confiance) plus tard.

Dans ce compromis, une solution de compromis consiste à adopter une solution hybride:

• High Trust CommitteeLe traitement des clés est effectué avec, par exemple, le seuil n / 3.

• Comité de calculest rotationnel, par exemple, avec un seuil N-1 (ou plusieurs comités informatiques différents avec différentes caractéristiques que les utilisateurs peuvent choisir).

Bien que cela soit théoriquement attrayant, il introduit également une complexité supplémentaire, comme la façon dont le comité informatique interagit avec le comité de confiance élevé.

Une autre façon de renforcer la sécurité consiste à exécuter des MPC dans le matériel de confiance pour maintenir le partage de clé dans une zone sécurisée.Cela rend plus difficile d’extraire ou d’utiliser le partage de clés pour d’autres opérations autres que les définitions de protocole.Au moins Zama et Arcium explorent l’angle de tee.

Des risques plus subtils incluent des cas Edge tels que l’ingénierie sociale, où, par exemple, toutes les entreprises d’un cluster MPC ont embauché un ingénieur principal pendant plus de 10 à 15 ans.

2. La technologie est-elle suffisamment mature?Si vous n’êtes pas assez mature, quel est le goulot d’étranglement?

Du point de vue des performances, le principal défi auquel les MPC sont confrontés sont les frais généraux de communication.Il croît avec la complexité de l’informatique et le nombre de nœuds dans le réseau (a besoin de plus de communication).Pour les cas d’utilisation de la blockchain, cela a deux implications pratiques:

1. Ensembles de petits opérateurs: Pour rendre la communication de communication contrôlable, la plupart des protocoles existants sont actuellement limités aux petits ensembles d’opérateurs.Par exemple, le réseau décrypté de Zama permet actuellement jusqu’à 4 nœuds (bien qu’ils prévoient de passer à 16).Selon l’indice de référence initial publié par Zama pour son réseau de décryptage (TKMS), même si un cluster avec seulement 4 nœuds n’est que de 0,5 à 1 seconde (le processus E2E complet prend plus de temps).Un autre exemple est le MPC implémenté par Taceo pour la base de données IRIS de WorldCoin, qui a 3 parties (en supposant 2/3 parties honnêtes).

   Source:Le discours de Zama à ETH CC

2. 

3. Ensembles d’opérateurs agréés: Dans la plupart des cas, les ensembles d’opérateurs sont sous licence.Cela signifie que nous comptons sur la réputation et les contrats juridiques, et non sur le plan économique ou crypto-sécurité.Le principal défi avec un ensemble d’opérateurs sans autorisation est l’incapacité de savoir si les gens se terminent hors de la chaîne.De plus, il nécessite des partages de clés de démarrage ou de réaffectation périodiques afin que les nœuds puissent entrer dynamiquement / quitter le réseau.Bien que l’ensemble de l’opérateur sans autorisation soit l’objectif ultime et comment le mécanisme POS est étendu pour atteindre les MPC seuils (par exemple, Zama), l’itinéraire d’autorisation semble être la meilleure voie à suivre pour le moment.

Méthode alternative

Un portefeuille complet de confidentialité comprend:

• FHE est utilisé pour déléguer les calculs de confidentialité

• ZKP est utilisé pour vérifier que le calcul du FHE est exécuté correctement

• MPC pour le décryptage des seuils

• Chaque nœud MPC s’exécute dans Tee pour une sécurité améliorée



Ceci est complexe, introduisant de nombreux extrêmes inexplorés, avec beaucoup de frais généraux et peut ne pas être pratique pendant de nombreuses années à venir.Un autre risque est que les gens puissent avoir un faux sentiment de sécurité en superposant ensemble plusieurs concepts complexes.Plus nous ajoutons de complexité et de confiance, plus il est difficile de déduire la sécurité de la solution globale.

Cela en vaut-il la peine?Cela en vaut peut-être la peine, mais il vaut également la peine d’explorer d’autres méthodes qui peuvent conduire à une efficacité de calcul considérablement meilleure, tandis que les garanties de confidentialité ne seront que légèrement plus faibles.Comme le souligne le Lyron de Seismic – nous devons nous concentrer sur les solutions les plus simples pour répondre à nos critères pour le niveau de confidentialité et les compromis acceptables nécessaires, plutôt que sur la conception trop pour cela.

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

Si ZK et FHE finissent par revenir à l’hypothèse de confiance du MPC, pourquoi ne pas utiliser directement MPC pour les calculs?Il s’agit d’une question raisonnable, et c’est quelque chose que des équipes telles que l’arcium, les sodalabs (utilisées par CoTi V2), Taceo et NIMLION essaient de faire.Notez que MPC se présente sous de nombreuses formes, mais parmi les trois principales méthodes, nous faisons référence ici à la base dePartage secretetCircuit à ordures (GC)plutôt qu’un protocole basé sur FHE qui utilise MPC pour le déchiffrement.

Bien que MPC ait été utilisé pour des calculs simples tels que les signatures distribuées et les portefeuilles plus sécurisés, le principal défi en calcul plus général avec MPC est les frais généraux de communication (augmentant avec la complexité du calcul et le nombre de nœuds impliqués).

Il existe des moyens de réduire les frais généraux, tels que le prétraitement hors ligne à l’avance (c’est-à-dire la partie la plus coûteuse du protocole) – l’arcine et les sodalabs explorent cela.Le calcul est ensuite effectué dans la phase en ligne, qui consomme certaines données générées dans la phase hors ligne.Cela réduit considérablement les frais généraux globaux de communication.

Le tableau suivant pour Sodalabs montre combien de temps il faut pour exécuter différents opcodes 1 000 fois dans son GCEVM(en microsecondes).Bien qu’il s’agisse d’un pas dans la bonne direction, il reste encore beaucoup de travail à faire pour améliorer l’efficacité et étendre l’opérateur défini au-delà de quelques nœuds.



Source: Sodalabs

L’avantage de l’approche basée sur ZK est que vous n’utilisez que MPC pour les cas d’utilisation qui nécessitent des calculs dans un état privé partagé.FHE rivalise plus directement avec MPC et s’appuie fortement sur l’accélération matérielle.

2. Environnement d’exécution de confiance

Récemment, l’intérêt pour le TEE a ravivé, qui peut être utilisé seul (une blockchain privée ou un coprocesseur basé sur le TEE) ou en combinaison avec d’autres animaux de compagnie tels que des solutions basées sur ZK (en utilisant uniquement le Tee).

Bien que les tees soient plus matures à certains égards et introduisent moins de performances, elles ne sont pas sans inconvénients.Premièrement, Tee a des hypothèses de confiance différentes (1 / N) et fournit des solutions matérielles plutôt que logicielles.Les critiques que les gens entendent souvent sont des vulnérabilités autour du passé de SGX, mais il convient de noter que le tee ≠ Intel sgx.Tee doit également faire confiance aux fournisseurs de matériel, qui sont chers (ce que la plupart des gens ne peuvent pas se permettre).Une solution au risque d’attaques physiques pourrait être d’exécuter des t-shirts dans l’espace pour gérer les missions critiques.

Dans l’ensemble, Tee semble être plus adapté aux preuves ou aux cas d’utilisation qui ne nécessitent que la confidentialité à court terme (décryptage de seuil, grand livre de disque sombre, etc.).La sécurité semble moins attrayante pour la confidentialité permanente ou à long terme.

3. DAC privés et autres moyens de compter sur des tiers de confiance pour protéger la vie privée

La confidentialité intermédiaire peut fournir une confidentialité pour empêcher l’accès des autres utilisateurs, mais les garanties de confidentialité proviennent entièrement de la confiance dans des 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é avec des garanties supplémentaires (chiffrement ou économique) et permet de réaliser correctement la vérification.

Un exemple est le comité de disponibilité des données privées (DAC); les membres des données de la DAC du magasin, et les utilisateurs leur font confiance pour stocker correctement les données et effectuer des mises à jour de transition de l’État.Un autre formulaire est le séquenceur agréé proposé par Tom Walpo.

Bien que cette approche ait un grand compromis en termes d’assurance de confidentialité, il peut être la seule alternative viable (du moins pour l’instant) en termes de coût et de performance.Par exemple, le protocole d’objectif prévoit d’utiliser des DAC privés pour implémenter le flux d’informations privées.Pour les cas d’utilisation tels que les sociaux en chaîne, le compromis entre la vie privée et le coût / la performance peut être raisonnable pour le moment (compte tenu du coût et des frais généraux des alternatives).

4. Adresse invisible

Une adresse invisible peut fournir une garantie de confidentialité similaire à la création d’une nouvelle adresse pour chaque transaction, mais le processus est automatiquement effectué sur le backend et n’est pas divulgué à l’utilisateur.Pour plus d’informations, consultez cet aperçu de Vitalik ou cet article qui creuse dans différentes approches.Les principaux joueurs de ce domaine incluent Umbra et Fluidkey.

Bien que les adresses invisibles fournissent une solution relativement simple, le principal inconvénient est qu’ils ajoutent uniquement des garanties de confidentialité aux transactions (paiements et transferts) et non à l’informatique générale.Cela les rend différents des trois autres solutions mentionnées ci-dessus.

De plus, les garanties de confidentialité fournies par les adresses invisibles ne sont pas aussi puissantes que les autres alternatives.L’anonymat peut être interrompu avec une analyse de regroupement simple, en particulier lorsque les transferts entrants et sortants ne sont pas dans une fourchette similaire (par exemple, 10 000 $ sont reçus, mais la transaction quotidienne moyenne coûte 10 à 100 $).Un autre défi avec des adresses invisibles est la mise à niveau des clés, qui nécessitent désormais des mises à niveau individuelles pour chaque portefeuille (le résumé du stockage des clés peut aider à résoudre ce problème).Du point de vue de l’expérience utilisateur, si le compte n’a pas de jetons de frais (tels que ETH), le protocole d’adresse invisible exige également que l’abstraction du compte ou le payeur paie les frais.

Risques pour notre argument

Compte tenu du rythme rapide du développement et de l’incertitude générale des différentes solutions technologiques, nous pensons qu’il existe des risques dans l’argument selon lequel MPC sera la solution finale.Nous ne pouvons pas finir par avoir besoin d’une forme de MPC, les principales raisons comprennent:

1. L’état privé partagé n’est pas aussi important que nous le pensons: dans ce cas, l’infrastructure basée sur ZK est plus susceptible de gagner car elle a des garanties de confidentialité plus fortes et des frais généraux plus bas que FHE.Il existe déjà des cas d’utilisation qui montrent que les systèmes basés sur ZK fonctionnent bien dans les cas d’utilisation orphelins, tels que le protocole de paiement privé Payy.

2. Les compromis de performance ne sont pas dignes des avantages de la protection de la confidentialité: on pourrait dire que l’hypothèse de fiducie d’un réseau MPC avec 2-3 concédants de licence n’est pas très différente d’un seul acteur centralisé, et qu’une augmentation significative du coût / des frais généraux ne vaut pas la peine il.Cela peut être vrai pour de nombreuses applications, en particulier les applications de faible valeur et sensibles aux coûts (comme les jeux ou les jeux).Cependant, il existe également de nombreux cas d’utilisation de grande valeur où la collaboration est actuellement très coûteuse (ou impossible) en raison de problèmes juridiques ou de frottement de coordination.Ce dernier est l’endroit où MPC et les solutions basées sur FHE peuvent briller.

3. La spécialisation bat la conception générale: construire de nouvelles chaînes et guider la communauté des utilisateurs et des développeurs est très difficile.Par conséquent, l’infrastructure universelle de confidentialité (L1 / L2) peut être difficile à attirer l’attention.Un autre problème implique une spécialisation; une conception de protocole unique est difficile pour couvrir l’ensemble de l’espace de compromis.Dans ce monde, les solutions qui offrent une confidentialité pour les écosystèmes existants (confidentialité en tant que service) ou des cas d’utilisation dédiés (tels que le paiement) l’emporteront.Cependant, nous sommes sceptiques quant à ce dernier car il apporte une complexité aux développeurs d’applications qui ont besoin de mettre en œuvre des techniques de chiffrement elles-mêmes (plutôt que de les abstraire).

4. La réglementation continue de gêner les essais de solutions de confidentialité: il s’agit d’un risque pour quiconque construit une infrastructure et des applications de confidentialité avec certaines garanties de confidentialité.Les cas d’utilisation non financiers sont confrontés à moins de risques réglementaires, mais il est difficile (impossible) de contrôler ce qui est construit au-dessus d’une infrastructure de confidentialité sans licence.Nous sommes susceptibles de résoudre les problèmes techniques avant de résoudre les problèmes réglementaires.

5. Pour la plupart des cas d’utilisation, les frais généraux des solutions MPC et FHE sont encore trop élevées: alors que les MPC sont principalement affectés par les frais généraux de communication, l’équipe FHE s’appuie fortement sur l’accélération matérielle pour améliorer ses performances.Mais si nous pouvons déduire le développement de matériel dédié du côté ZK, cela prendra beaucoup plus de temps que la plupart des gens ne le pensent avant d’obtenir le matériel disponible pour la production.Les équipes dédiées à l’accélération matérielle incluent Optalysys, Fhela et Niobium.

Résumé

En fin de compte, la force de la chaîne dépend de son maillon le plus faible.Dans le cas d’une infrastructure de confidentialité programmable, siNous voulons qu’il gère l’état privé partagé sans point d’échec unique, puis la garantie de fiducie se résume à la garantie de MPC.

Bien que ce post semble être une critique de MPC, ce n’est pas le cas.MPC a considérablement amélioré la situation actuelle de s’appuyer sur des tiers centralisés.Nous pensons que le principal problème est qu’il y a une fausse confiance dans toute l’industrie et que le problème est couvert.Au lieu de cela, nous devons faire face au problème de front et nous concentrer sur l’évaluation des risques potentiels.

Cependant, tous les problèmes ne doivent pas être résolus en utilisant les mêmes outils.Bien que nous pensons que MPC est l’objectif ultime, d’autres approches sont également des options viables tant que les frais généraux des solutions motivées par MPC restent élevés.Nous valons toujours la peine de considérer quelle approche convient le mieux aux besoins / caractéristiques spécifiques du problème que nous essayons de résoudre et à quels compromis nous sommes prêts à faire.

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