Partie 1 de notre série sur la confidentialitéa couvert ce que "la vie privée" implique, comment la vie privée dans les réseaux blockchain diffère de la vie privée web2, et pourquoi il est difficile à réaliser dans les blockchains.

L'argument principal de ce message est que si l'état final souhaitable est d'avoir une infrastructure de confidentialité programmable capable de gérer un état privé partagé sans aucun point de défaillance unique, alors tous les chemins mènent à MPC. Nous explorons également la maturité de MPC et ses hypothèses de confiance, mettons en évidence des approches alternatives, comparons les compromis et fournissons un aperçu de l'industrie.

Construisons-nous tous la même chose? Continuez à lire pour le découvrir.

Grâce à Avishay (SodaLabs), Lukas (Taceo) Michael (Équilibre), et Nico (Arcium) pour les discussions qui ont contribué à façonner ce billet.

Ce qui peut être, déchargé de ce qui a été

L'infrastructure de confidentialité existante dans les blockchains est conçue pour gérer des cas d'utilisation très spécifiques, tels que les paiements privés ou les votes. C'est une vision assez étroite et reflète surtout ce pour quoi les blockchains sont actuellement utilisées (le trading, les transferts et la spéculation).Tom Walpo l'a mis - La cryptographie souffre d'un paradoxe de Fermi :

Outre l'augmentation de la liberté individuelle, nous croyons que la confidentialité est une condition préalable à l'expansion de l'espace de conception des chaînes de blocs au-delà de la méta spéculative actuelle. De nombreuses applications requièrent un état privé et/ou une logique cachée pour fonctionner correctement:

• État caché: La grande majorité des cas d'utilisation financière nécessitent (au minimum) la confidentialité vis-à-vis des autres utilisateurs et de nombreux jeux multijoueurs sont nettement moins amusants à jouer sans un certain état caché (par exemple, si tous les joueurs à la table de poker pouvaient voir les cartes des autres).
• Logique cachée : Certaines utilisations nécessitent de cacher une partie de la logique tout en permettant à d'autres d'utiliser l'application, comme un moteur de correspondance, une stratégie de trading sur chaîne, etc.

L'analyse empirique (à la fois web2 et web3) montre que la plupart des utilisateurs ne sont pas disposés à payer plus ou à sauter à travers des boucles supplémentaires pour une vie privée accrue, et nous sommes d'accord que la vie privée n'est pas un argument de vente en soi. Cependant, cela permet de nouveaux cas d'utilisation plus significatifs (et espérons-le) d'exister sur les blockchains, nous permettant de sortir du Paradoxe de Fermi.

Les technologies améliorant la confidentialité (MPC) et les solutions de cryptographie moderne (“cryptographie programmable"）sont les éléments fondamentaux pour réaliser cette vision (voir annexepour plus d'informations sur les différentes solutions disponibles et leurs compromis).

Trois hypothèses qui façonnent nos opinions

Trois hypothèses clés façonnent notre vision de l'évolution possible de l'infrastructure de confidentialité dans les blockchains :

1. La cryptographie sera abstraite des développeurs d'applications: la plupart des développeurs d'applications ne veulent pas (ou ne savent pas comment) gérer la cryptographie nécessaire à la confidentialité. Il est déraisonnable de s'attendre à ce qu'ils mettent en œuvre leur propre cryptographie et construisent des chaînes spécifiques à l'application (par exemple, ZcashouNamada) ou des applications privées au-dessus d’une chaîne publique (par exemple, Tornado Cash). Il s’agit tout simplement d’une complexité et d’une surcharge excessives, ce qui limite actuellement l’espace de conception pour la plupart des développeurs (ils ne peuvent pas créer d’applications qui nécessitent des garanties de confidentialité). Pour cette raison, nous pensons que la complexité de la gestion de la partie cryptographie doit être abstraite des développeurs d’applications. Deux approches sont l’infrastructure de confidentialité programmable (une L1/L2 privée partagée) ou la « confidentialité en tant que service » qui permet d’externaliser le calcul confidentiel.
2. De nombreux cas d’utilisation (probablement plus que nous ne le pensons) nécessitent un état privé partagé : Comme mentionné précédemment, de nombreuses applications nécessitent un état et/ou une logique cachés pour fonctionner correctement. L’état privé partagé est un sous-ensemble de cela, où plusieurs parties calculent sur le même morceau d’état privé. Bien que nous puissions faire confiance à une partie centralisée pour le faire à notre place et nous arrêter là, nous voulons idéalement le faire d’une manière qui minimise la confiance afin d’éviter les points de défaillance uniques. Les preuves à divulgation nulle de connaissance (ZKP) ne peuvent à elles seules y parvenir - nous devons tirer parti d’outils supplémentaires tels que les environnements d’exécution de confiance (TEE), le chiffrement entièrement homomorphe (FHE) et/ou le calcul multipartite (MPC).
3. Les ensembles blindés plus grands maximisent la confidentialité: La plupart des informations sont révélées lorsque entrer ou sortirle jeu protégé, nous devrions donc essayer de le minimiser. Avoir plusieurs applications privées construites sur la même blockchain peut aider à renforcer les garanties de confidentialité en augmentant le nombre d'utilisateurs et de transactions au sein du même jeu protégé.

Fin du jeu de l'infrastructure de confidentialité

Avec les hypothèses ci-dessus à l'esprit - quel est l'objectif final de l'infrastructure de confidentialité dans les blockchains ? Existe-t-il une approche adaptée à chaque application ? Une technologie améliorant la confidentialité pour tous les dominer ?

Pas tout à fait. Tous ceux-ci ont des compromis différents et nous voyons déjà qu'ils sont combinés de différentes manières. Au total, nous avons identifié 11 approches différentes (voir annexe).

Aujourd'hui, les deux approches les plus populaires pour construire une infrastructure de confidentialité dans les blockchains s'appuient sur des ZKPs ou des FHE. Cependant, les deux ont des défauts fondamentaux:

• Les protocoles de confidentialité basés sur ZK avec une preuve côté client peuvent offrir des garanties de confidentialité solides mais ne permettent pas à plusieurs parties de calculer sur le même état privé. Cela limite l'expressivité, c'est-à-dire les types d'applications que les développeurs peuvent créer.
• FHE permet les calculs sur des données chiffrées et l'état privé partagé, mais soulève la question de savoir qui possède cet état, c'est-à-dire qui détient la clé de décryptage. Cela limite la force des garanties de confidentialité et la confiance que nous pouvons accorder à ce qui est privé aujourd'hui reste privé demain.

Si l'état final souhaité est d'avoir une infrastructure de confidentialité programmable capable de gérer un état privé partagé sans aucun point de défaillance unique, alors les deux routes mènent à MPC:

Notez que même si ces deux approches convergent finalement, MPC est utilisé pour des choses différentes :

• Réseaux ZKP: MPC est utilisé pour ajouter de l'expressivité en permettant le calcul sur un état privé partagé.
• Réseaux FHE : MPC est utilisé pour renforcer la sécurité et garantir la confidentialité en distribuant la clé de déchiffrement à un comité MPC (plutôt qu'à une seule tierce partie).

Alors que la discussion commence à évoluer vers une vision plus nuancée, les garanties derrière ces différentes approches restent peu explorées. Étant donné que nos hypothèses de confiance se résument à celles de MPC, les trois questions clés à poser sont :

1. Quelle est la force des garanties de confidentialité que les protocoles MPC peuvent fournir dans les blockchains?
2. La technologie est-elle suffisamment mature ? Sinon, quels sont les obstacles ?
3. Compte tenu de la force des garanties et des surcoûts qu'elle introduit, cela a-t-il du sens par rapport aux approches alternatives?

Abordons ces questions plus en détail.

Analyse des risques et des faiblesses avec MPC

Chaque fois qu'une solution utilise le FHE, il faut toujours se demander : "Qui détient la clé de décryptage ?". Si la réponse est "le réseau", la question suivante est : "Quelles entités réelles composent ce réseau ?". Cette dernière question est pertinente pour tous les cas d'utilisation reposant sur le MPC sous une forme ou une autre.

Source: Discours de Zama à ETH CC

Le principal risque avec MPC est la collusion, c’est-à-dire qu’un nombre suffisant de parties agissent de manière malveillante et s’entendent pour déchiffrer les données ou détourner les calculs. La collusion peut être convenue hors chaîne et n’est révélée que si les parties malveillantes font quelque chose pour qu’elle soit évidente (chantage, frappe de jetons à partir de rien, etc.). Inutile de dire que cela a des implications importantes pour les garanties de confidentialité que le système peut fournir. Le risque de collusion dépend :

• Quel seuil de parties malveillantes le protocole peut-il supporter ?
• Quels partis composent le réseau et à quel point sont-ils dignes de confiance?
• Nombre de parties différentes qui participent au réseau et leur répartition - Y a-t-il des vecteurs d'attaque communs ?
• Le réseau est-il sans permission ou avec permission (basé sur l'enjeu économique par rapport à la réputation/au droit)?
• Quelle est la punition pour un comportement malveillant ? La collusion est-elle le résultat théoriquement optimal du jeu ?

1. Quelle est la solidité des garanties de confidentialité que les protocoles MPC peuvent fournir dans les blockchains?

TLDR: Pas aussi solide que nous le souhaiterions, mais plus fort que de compter uniquement sur un tiers centralisé.

Le seuil requis pour décrypter dépend du schéma MPC choisi - principalement un compromis entre la vivacité ("livraison de sortie garantie") et la sécurité. Vous pouvez avoir un schéma N/N qui est très sécurisé mais qui s'effondre si un seul nœud se déconnecte. D'autre part, les schémas N/2 ou N/3 sont plus robustes mais présentent un risque plus élevé de collusion.

Les deux conditions à équilibrer sont :

1. Les informations secrètes ne sont jamais divulguées (par exemple la clé de déchiffrement)
2. Les informations secrètes ne disparaissent jamais (même si disons qu'1/3 des parties partent soudainement).

Le schéma choisi varie selon les implémentations. Par exemple, Zama vise N/3, tandis que Arcium met actuellement en œuvre un schéma N/Nmais visant ultérieurement à soutenir également des schémas avec des garanties de vivacité plus élevées (et des hypothèses de confiance plus importantes).

Un compromis le long de cette frontière de compromis serait d'avoir une solution mixte :

• Comité de haute confiance qui gère la manipulation des clés avec par exemple un seuil N/3.
• Les comités de calcul qui sont rotatifs et ont par exemple un seuil N-1 (ou plusieurs comités de calcul différents avec des caractéristiques différentes pour que les utilisateurs puissent choisir).

Bien que cela soit attrayant en théorie, cela introduit également une complexité supplémentaire telle que la manière dont le comité de calcul interagirait avec le comité de confiance élevée.

Une autre manière de renforcer les garanties de sécurité est d'exécuter le MPC dans un matériel de confiance, de sorte que les partages de clés soient conservés à l'intérieur d'une enclave sécurisée. Cela rend plus difficile l'extraction ou l'utilisation des partages de clés à d'autres fins que celles définies par le protocole. Au moins ZamaetArciumexplorer l'angle TEE.

Des risques plus nuancés incluent des cas marginaux autour de choses comme l'ingénierie sociale, où par exemple un ingénieur principal est employé par toutes les entreprises incluses dans le cluster MPC pendant 10 à 15 ans.

2. La technologie est-elle suffisamment mature ? Sinon, quels sont les obstacles ?

D'un point de vue de la performance, le principal défi de MPC est la surcharge de communication. Elle augmente avec la complexité des calculs et le nombre de nœuds qui font partie du réseau (plus de communication est requise). Pour les cas d'utilisation de la blockchain, cela conduit à deux implications pratiques :

1. Petit ensemble d'opérateurs : Pour maintenir une surcharge de communication gérable, la plupart des protocoles existants sont actuellement limités à de petits ensembles d'opérateurs. Par exemple, le réseau de décryptage de Zama permet actuellement un maximum de 4 nœuds (bien qu'ils prévoient de passer à 16). Selon les benchmarks initiaux publiés par Zama pour leur réseau de décryptage (TKMS), il faut 0,5 à 1s pour décrypter même avec seulement un cluster de 4 nœuds (le flux complet de bout en bout prend beaucoup plus de temps). Un autre exemple est Taceo’s Mise en œuvre de MPC pour la base de données iris de Worldcoin, qui comporte 3 parties (avec une hypothèse de parti honnête de 2/3).

1. Source: Présentation de Zama à l’ETH CC
2. Ensemble d'opérateurs autorisé : Dans la plupart des cas, l'ensemble des 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 cryptographique. Le principal défi avec un ensemble d'opérateurs sans autorisation est qu'il n'y a aucun moyen de savoir si les gens collaborent en dehors de la chaîne. De plus, cela nécessiterait un amorçage régulier ou une redistribution de la clé partagée pour que les nœuds puissent entrer ou sortir dynamiquement du réseau. Bien que les ensembles d'opérateurs sans autorisation soient l'objectif final et qu'il y ait des recherches en cours sur la manière d'étendre un mécanisme de PoS pour un MPC seuil (par exemple par Zama), la voie autorisée semble être la meilleure voie à suivre pour l'instant.

Approches alternatives

Le cocktail de confidentialité complet se compose de:

• FHE pour le calcul privé délégué
• ZKP pour vérifier que le calcul FHE a été correctement exécuté
• MPC pour le déchiffrement seuillé
• Chaque nœud MPC s'exécute dans un TEE pour une sécurité supplémentaire

Ceci est complexe, introduit de nombreux cas limites inexplorés, a un coût élevé et pourrait ne pas être pratiquement réalisable pendant de nombreuses années à venir. Un autre risque est le faux sentiment de sécurité que l'on peut avoir en ajoutant plusieurs concepts complexes les uns sur les autres. Plus nous ajoutons de complexité et d'hypothèses de confiance, plus il devient difficile de raisonner sur la sécurité de la solution globale.

Est-ce que ça en vaut la peine ? Peut-être, mais il vaut également la peine d'explorer des approches alternatives qui pourraient apporter une efficacité de calcul nettement meilleure au détriment de garanties de confidentialité légèrement moins solides. Comme Lyron de Seismicnoté - nous devrions nous concentrer sur la solution la plus simple qui satisfait nos critères pour le niveau de confidentialité requis et les compromis acceptables, plutôt que de sur-ingénierie juste pour le plaisir.

1. Utiliser MPC Directement Pour le Calcul Général

Si à la fin, à la fois ZK et FHE reviennent aux hypothèses de confiance de MPC, pourquoi ne pas utiliser directement MPC pour le calcul ? C'est une question valide et quelque chose que des équipes comme Gate.io ont également pris en compte.Arcium,SodaLabs (en anglais seulement) (utilisé par Cotiv2),Taceo, et Nillion que nous essayons de faire. Notez que MPC prend de nombreuses formes, mais parmi les trois approches principales, nous nous référons ici au partage secret et aux protocoles basés sur des circuits brouillés (GC), et non aux protocoles basés sur FHE qui utilisent MPC pour le déchiffrement.

Bien que le MPC soit déjà utilisé pour des calculs simples tels que des signatures distribuées et des portefeuilles plus sécurisés, le principal défi de l'utilisation du MPC pour des calculs plus généraux est la surcharge de communication (qui augmente avec la complexité du calcul et le nombre de nœuds impliqués).

Il existe plusieurs façons de réduire les frais généraux, comme en effectuant le prétraitement (c'est-à-dire les parties les plus coûteuses du protocole) à l'avance et hors ligne - quelque chose à la foisArciumetSodaLabsexplorer. Le calcul est ensuite exécuté dans la phase en ligne, ce qui consomme une partie des données produites dans la phase hors ligne. Cela réduit considérablement la surcharge de communication globale.

Le tableau ci-dessous de SodaLabs montre des benchmarks initiaux sur la durée nécessaire pour exécuter différentes opcodes 1 000 fois dans leur gcEVM (notée en microsecondes). Bien que cela soit un pas dans la bonne direction, il reste encore beaucoup de travail à faire pour améliorer l'efficacité et étendre l'ensemble des opérateurs au-delà de quelques nœuds.

Source : SodaLabs

L'avantage de l'approche basée sur ZK est que vous n'utilisez MPC que pour les cas d'utilisation qui nécessitent le calcul sur un état privé partagé. FHE est en concurrence plus directe avec MPC et repose fortement sur l'accélération matérielle.

2. Environnements d'exécution sécurisés

Il y a récemment eu un intérêt renouvelé pour les TEE, qui peuvent être exploités soit de manière isolée (blockchains privées basées sur TEE ou coprocesseurs) soit en combinaison avec d'autres PET tels que des solutions basées sur ZK (utilisation uniquement de TEE pour le calcul sur un état privé partagé).

Bien que les TEE soient, à certains égards, plus matures et présentent moins de surcharge de performance, ils ne sont pas sans inconvénients. Tout d'abord, les TEE ont des hypothèses de confiance différentes (1/N) et offrent une solution basée sur le matériel plutôt que sur le logiciel. Une critique souvent entendue concerne les erreurs passées.vulnérabilités de SGX, mais il convient de noter que TEE ≠ Intel SGX. Les TEE nécessitent également de faire confiance au fournisseur de matériel et le matériel est coûteux (pas accessible à la plupart). Une solution au risque d'attaques physiques pourrait être de exécuter des TEE dans l'espacepour des choses cruciales pour la mission.

Dans l'ensemble, les TEE semblent plus adaptés aux cas d'utilisation nécessitant uniquement une confidentialité à court terme (déchiffrement seuil, carnets d'ordres sombres, etc.). Pour une confidentialité permanente ou à long terme, les garanties de sécurité semblent moins attrayantes.

3. DAC privé et autres approches reposant sur des tiers de confiance pour la confidentialité

La confidentialité intermédiaire peut offrir une confidentialité vis-à-vis des autres utilisateurs, mais les garanties de confidentialité reposent uniquement sur la confiance en un tiers (point de défaillance unique). Bien qu'elle ressemble à la « vie privée web2 » (la confidentialité vis-à-vis des autres utilisateurs), elle peut être renforcée par des garanties supplémentaires (cryptographiques ou économiques) et permettre la vérification de l'exécution correcte.

Les comités de disponibilité de données privées (DAC) en sont un exemple ; Les membres du DAC stockent des données hors chaîne et les utilisateurs leur font confiance pour stocker correctement les données et appliquer les mises à jour de transition d'état. Une autre variante de ceci est le Séquenceur franchiséproposé par Tom Walpo.

Bien que cette approche fasse d’importants compromis dans les garanties de confidentialité, elle pourrait être la seule alternative réalisable pour les applications à faible valeur ajoutée et hautes performances en termes de coût et de performances (pour l’instant du moins). Un exemple est Protocole de l’objectif, qui prévoit d'utiliser un DAC privé pour obtenir des flux privés. Pour des cas d'utilisation tels que les réseaux sociaux on-chain, le compromis entre la confidentialité et le coût/la performance est probablement raisonnable pour le moment (étant donné le coût et les frais généraux des alternatives).

4. Adresses furtives

Les adresses furtives peuvent offrir des garanties de confidentialité similaires à la création d'une nouvelle adresse pour chaque transaction, mais le processus est automatisé en arrière-plan et abstrait pour les utilisateurs. Pour plus d'informations, voir ceci aperçu par Vitalik ou ceci Plongez dans différentes approchesLes acteurs principaux de ce domaine comprennent OmbreetClé fluide.

Bien que les adresses furtives offrent une solution relativement simple, le principal inconvénient est qu'elles ne peuvent ajouter des garanties de confidentialité que pour les transactions (paiements et transferts), et non pour le calcul à usage général. Cela les distingue des trois autres solutions mentionnées ci-dessus.

De plus, les garanties de confidentialité fournies par les adresses furtives ne sont pas aussi fortes que celles des alternatives. L’anonymat peut être rompu avec analyse de regroupement simple, en particulier si les virements entrants et sortants ne se situent pas dans une fourchette similaire (p. ex., recevoir 10 000 $, mais dépenser en moyenne de 10 $ à 100 $ pour les transactions courantes). Un autre défi avec les adresses furtives est la mise à niveau des clés, qui doit aujourd’hui être effectuée individuellement pour chaque portefeuille (les cumuls de magasins de clés pourraient aider à résoudre ce problème). Du côté de l’expérience utilisateur, les protocoles d’adresses furtives nécessitent également une abstraction de compte ou un paymaster pour couvrir les frais si le compte n’a pas le jeton de frais (par exemple, ETH).

Risques pour notre thèse

Compte tenu du rythme rapide du développement et de l’incertitude générale autour des différentes solutions techniques, il existe plusieurs risques pour notre thèse selon laquelle le MPC est la fin du jeu. Les principales raisons pour lesquelles nous n’aurons peut-être pas besoin de MPC sous une forme ou une autre sont les suivantes :

1. L'état privé partagé n'est pas aussi important que nous le prétendons : Dans ce cas, l'infrastructure basée sur ZK est mieux placée pour l'emporter car elle offre des garanties de confidentialité plus solides et un surcoût moindre que FHE. Il existe déjà des cas d'utilisation où les systèmes basés sur ZK fonctionnent bien pour des cas d'utilisation isolés, tels que le protocole de paiement privé.Payy.
2. Le compromis en termes de performances ne vaut pas l’avantage des garanties de confidentialité : on pourrait faire valoir que les hypothèses de confiance d’un réseau MPC avec 2 ou 3 parties autorisées ne sont pas significativement différentes de celles d’un seul acteur centralisé et que l’augmentation significative des coûts/frais généraux n’en vaut pas la peine. Cela peut être vrai pour de nombreuses applications, en particulier celles de faible valeur et sensibles aux coûts (par exemple, les réseaux sociaux ou les jeux). Cependant, il existe également de nombreux cas d’utilisation à forte valeur ajoutée où la collaboration est actuellement très coûteuse (voire impossible) en raison de problèmes juridiques ou de frictions de coordination importantes. C’est dans ce dernier domaine que les solutions basées sur MPC et FHE peuvent briller.
3. La spécialisation l'emporte sur la conception à usage général : Construire une nouvelle chaîne et lancer une communauté d'utilisateurs et de développeurs est difficile. Pour cette raison, l'infrastructure de confidentialité à usage général (L1/L2s) peut avoir du mal à prendre de l'ampleur. Une autre question concerne la spécialisation ; il est très difficile pour une conception de protocole unique de couvrir l'ensemble de l'espace de compromis. Dans ce monde, les solutions qui offrent la confidentialité pour les écosystèmes existants (confidentialité en tant que service) ou pour des cas d'utilisation spécialisés (par exemple, les paiements) prévaudraient. Cependant, nous sommes sceptiques quant à cette dernière option en raison de la complexité qu'elle introduit pour les développeurs d'applications qui devraient mettre en œuvre eux-mêmes certaines cryptographies (plutôt que de les abstraire).
4. La réglementation continue de freiner l'expérimentation autour des solutions de confidentialité : c'est un risque pour toute personne construisant à la fois une infrastructure de confidentialité et des applications avec certaines garanties de confidentialité. Les cas d'utilisation non financiers présentent moins de risques réglementaires, mais il est difficile (voire impossible) de contrôler ce qui est construit sur une infrastructure de confidentialité sans autorisation. Nous pourrions bien résoudre les problèmes techniques avant les problèmes réglementaires.
5. La surcharge des schémas basés sur MPC et FHE reste trop élevée pour la plupart des cas d’utilisation : alors que MPC souffre principalement de la surcharge de communication, les équipes FHE s’appuient fortement sur l’accélération matérielle pour améliorer leurs performances. Cependant, si nous pouvons extrapoler l’évolution du matériel spécialisé du côté de ZK, il faudra beaucoup plus de temps que la plupart des gens ne le souhaiteraient avant d’obtenir du matériel FHE prêt pour la production. Voici quelques exemples d’équipes travaillant sur l’accélération matérielle FHE Optialysys, fhela, et Niobium.

Résumé

Finalement, une chaîne n'est aussi solide que son maillon le plus faible. Dans le cas d'une infrastructure de confidentialité programmable, les garanties de confiance se résument à celles du MPC si nous voulons qu'il puisse gérer un état privé partagé sans point de défaillance unique.

Bien que cet article puisse sembler critique à l’égard de MPC, ce n’est pas le cas. MPC offre une énorme amélioration par rapport au statu quo actuel qui consiste à s’appuyer sur des tiers centralisés. Le principal problème, à notre avis, est le faux sentiment de confiance dans l’ensemble de l’industrie et les problèmes balayés sous le tapis. Au lieu de cela, nous devrions traiter les problèmes de front et nous concentrer sur l’évaluation des risques potentiels.

Cependant, tous les problèmes n’ont pas besoin d’être résolus à l’aide des mêmes outils. Même si nous pensons que le MPC est la fin du jeu, les approches alternatives sont des options viables tant que les frais généraux des solutions alimentées par MPC restent élevés. Il vaut toujours la peine de réfléchir à l’approche qui correspond le mieux aux besoins/caractéristiques spécifiques des problèmes que nous essayons de résoudre et aux compromis que nous sommes prêts à faire.

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

Annexe 1: Différentes approches de la confidentialité dans les blockchains

Technologies d’amélioration de la protection de la vie privée, ou PET, visent à améliorer un ou plusieurs aspects mentionnés ci-dessus. Plus concrètement, ce sont des solutions techniques visant à protéger les données lors du stockage, du calcul et de la communication.

Il existe de nombreux PET différents, mais les plus pertinents pour l’industrie de la blockchain incluent la soupe à trois lettres - ZKP, MPC, FHE et TEE - ainsi que des méthodes supplémentaires telles que les adresses furtives :

Ces PET peuvent être combinés de différentes manières pour atteindre des compromis et des hypothèses de confiance différents. Nous avons également des solutions qui reposent sur un tiers de confiance (vie privée intermédiée), telles que des comités de disponibilité de données privées (DAC). Celles-ci peuvent permettre la confidentialité vis-à-vis des autres utilisateurs, mais les garanties de confidentialité ne proviennent que de la confiance en un tiers. Dans ce sens, cela ressemble à la « vie privée web2 » (vie privée vis-à-vis des autres utilisateurs), mais elle peut être renforcée par des garanties supplémentaires (cryptographiques ou économiques).

Au total, nous avons identifié 11 approches différentes pour garantir une certaine confidentialité dans les réseaux blockchain. Certains compromis observés incluent :

• Confidentialité de confiance par rapport à la confidentialité minimisée de confiance (y a-t-il un point unique de défaillance ?)
• Approche matérielle vs logicielle
• Instances isolées vs combinaison de plusieurs PETs
• L1 vs L2
• Nouvelle chaîne vs confidentialité supplémentaire aux chaînes existantes ("confidentialité en tant que service")
• Taille de l'ensemble protégé (Multi-chaîne > Mono-chaîne > Application > Actif unique)

Annexe 2 : Aperçu de l'industrie

Au sein de ces 11 catégories, de nombreuses entreprises différentes travaillent sur une ou plusieurs solutions. Ci-dessous se trouve un aperçu (non exhaustif) de l'état actuel de l'industrie :

Avertissement :

1. Cet article est repris de [Gate]équilibre], Tous les droits d’auteur appartiennent à l’auteur original [Hannes Huitula]. 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 vues et opinions exprimées dans cet article sont uniquement celles de l'auteur et ne constituent aucun conseil en matière d'investissement.
3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe de Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.