)

Idées principales :

1. La FHE promet d'être le "Saint Graal de la cryptographie", mais de nombreux problèmes de performance, d'expérience des développeurs et de sécurité limitent son adoption actuelle.

2. Comme le montre le graphique ci-dessus, la FHE devra être utilisée parallèlement aux ZKP et aux MPC pour mettre en place un système d'État partagé véritablement confidentiel et sécurisé.

3. la FHE évolue rapidement : développement de nouveaux compilateurs, de nouvelles bibliothèques, de nouveaux matériels, etc. Sans oublier que FHE bénéficie immensément de la R&D des entreprises du Web2 (Intel, Google, DARPA, etc.).

4) Au fur et à mesure que la FHE et l'écosystème qui l'entoure gagnent en maturité, nous nous attendons à ce que la "FHE vérifiable" devienne la norme. Les applications FHE peuvent choisir de confier le calcul et la vérification à des coprocesseurs FHE.

5. une limitation fondamentale du FHE onchain est "qui détient la clé de décryptage ?" Le décryptage à seuil et le MPC offrent des solutions, mais ils sont généralement limités par un compromis de performance & sécurité.

Introduction :

La nature transparente des blockchains est une arme à double tranchant ; si l'ouverture et l'observabilité des blockchains sont belles, elles constituent un obstacle fondamental à l'adoption par les entreprises.

Depuis près d'une décennie, la protection de la vie privée sur la chaîne est l'un des problèmes les plus difficiles à résoudre dans le domaine des cryptomonnaies. Bien que de nombreuses équipes construisent des systèmes basés sur le ZK pour assurer la confidentialité de la chaîne, ils ne peuvent pas prendre en charge l'état partagé et crypté. Pourquoi ? En bref, parce que ces programmes sont fonction d'une série de ZKP et qu'en tant que tels, il est impossible pour quiconque d'appliquer une logique arbitraire à l'état actuel. Qu'est-ce que cela signifie ? En fait, nous ne pouvons pas construire des applications confidentielles à état partagé (pensez à Uniswap privé) en utilisant uniquement des ZKP.

Cependant, des avancées récentes ont montré que la combinaison des ZKP avec le chiffrement entièrement homomorphe (FHE) pouvait permettre de réaliser un DeFi confidentiel et entièrement généralisable. Comment ? Comme le montre le graphique ci-dessus, les ZKP peuvent prouver l'intégrité des entrées de l'utilisateur et du calcul, et le FHE peut traiter le calcul lui-même.

Alors que la FHE promet d'être le "Saint Graal de la cryptographie", nous tentons de fournir une analyse objective du domaine, de ses différents défis et des solutions possibles. Nous couvrons les sujets suivants sur la chaîne FHE :

• Schémas, bibliothèques et compilateurs de la FHE
• Décryptage sécurisé des seuils
• ZKP pour les données de l'utilisateur + la partie informatique
• Couche DA programmable et évolutive
• Matériel FHE

Schémas, bibliothèques et compilateurs de la FHE

Défi : schémas, bibliothèques et compilateurs FHE naissants

Le goulot d'étranglement fondamental de la FHE onchain réside dans son retard en matière d'outils et d'infrastructures de développement. Contrairement aux ZKP ou aux MPC, FHE n'existe que depuis 2009 et a donc bénéficié d'un délai beaucoup plus court pour arriver à maturité.

Les principales limites du FHE DevEx sont les suivantes :

• Un langage frontal facile à utiliser pour que les développeurs puissent coder sans avoir de connaissances approfondies sur la cryptographie.
• Un compilateur FHE entièrement fonctionnel qui peut faire tout le sale boulot. (Sélection des paramètres, optimisation SIMD pour BGV/BFV et optimisation parallèle)
• Les schémas FHE existants (en particulier TFHE) sont environ 1000 fois plus lents que le calcul simple.

Pour bien comprendre les subtilités de l'intégration de FHE, parcourons le parcours du développeur :

La première étape de l'intégration de la FHE dans votre application consiste à choisir un schéma de FHE à utiliser. Le tableau suivant explique les principaux systèmes :

Comme le montre le tableau ci-dessus, les circuits booléens tels que FHEW & TFHE ont l'amorçage le plus rapide et peuvent éviter une procédure de sélection des paramètres assez complexe ; ils pourraient être utilisés pour des calculs arbitraires/génériques mais sont relativement lents ; tandis que BGV/BFV pourraient convenir pour le DeFi général car ils sont plus efficaces pour les calculs arithmétiques de haute précision, mais les développeurs doivent connaître la profondeur du circuit à l'avance pour configurer tous les paramètres du schéma. À l'autre extrémité du spectre, CKKS prend en charge la multiplication homomorphique où les erreurs de précision sont autorisées, ce qui le rend optimal pour les cas d'utilisation non précis tels que la ML.

En tant que développeur, vous devez choisir une solution FHE avec beaucoup de soin, car cela affectera toutes les autres décisions de conception et les performances futures. En outre, plusieurs paramètres clés sont essentiels à la mise en place correcte du système FHE, tels que le choix de la taille du module et le rôle du degré polynomial.

En ce qui concerne les bibliothèques, les caractéristiques et les capacités des bibliothèques les plus populaires de l'enseignement supérieur sont présentées dans le tableau ci-dessous :

Mais les bibliothèques ont également des relations différentes avec les schémas et les compilateurs, comme indiqué ci-dessous :

Après avoir sélectionné la solution FHE, les développeurs doivent définir les paramètres. Une sélection appropriée des paramètres aura un impact considérable sur les performances du système FHE. Plus difficile, cela nécessite une certaine compréhension de l'algèbre abstraite, des opérations spécifiques à l'EEF telles que la relinéarisation et la commutation analogique-numérique, et des circuits arithmétiques ou binaires. Enfin, pour une sélection efficace des paramètres, il est nécessaire d'avoir une compréhension conceptuelle de la manière dont ils affectent le schéma de l'EEF.

À ce stade, les développeurs peuvent se poser la question :

Quelle doit être la taille de mon espace de texte en clair ? Quelle est l'ampleur des messages chiffrés acceptables ? Où puis-je paralléliser les calculs ? Et bien d'autres encore...

En outre, bien que le FHE puisse prendre en charge des calculs arbitraires, les développeurs doivent changer d'état d'esprit lorsqu'ils écrivent des programmes FHE. Par exemple, on ne peut pas écrire une branche (if-else) dépendant d'une variable dans le programme, parce que les programmes ne peuvent pas comparer directement les variables comme des données ordinaires. Au lieu de cela, les développeurs doivent modifier leur code pour passer des branches à une sorte de calcul qui pourrait intégrer les conditions de toutes les branches. De même, cela empêche les développeurs d'écrire des boucles dans leur code.

En bref, pour un développeur non initié à FHE, il est pratiquement impossible d'intégrer FHE dans son application. L'abstraction des complexités présentées par FHE nécessitera un outil de développement/infra important.

Solution :

1. Compilateurs FHE spécifiques à Web3

Bien qu'il existe déjà des compilateurs FHE construits par des entreprises telles que Google et Microsoft, ils sont.. :

• N'est pas conçu dans un souci de performance, ce qui multiplie par 1000 le surcoût par rapport à l'écriture directe des circuits.
• Optimisé pour CKKS (aka ML) et pas aussi bénéfique pour BFV/BGV nécessaire pour DeFi
• Il n'est pas conçu pour le Web3. Ne permet pas la compatibilité avec les schémas ZKP, le chaînage de programmes, etc.

Jusqu'au compilateur Sunscreen FHE. Il s'agit d'un compilateur natif Web3 qui offre certaines des meilleures performances pour les opérations arithmétiques (pensez à DeFi) sans accélérateur matériel. Sunscreen a automatisé non seulement la sélection des paramètres, mais aussi le codage des données, la sélection des clés, la relinéarisation et la commutation des modules, la mise en place des circuits et l'implémentation des opérations de type SIMD.

À l'avenir, nous espérons voir d'autres optimisations non seulement dans le compilateur Sunscreen, mais aussi dans d'autres équipes construisant leurs propres implémentations qui prennent en charge d'autres langages de haut niveau.

1. Nouvelle bibliothèque FHE

Tandis que les chercheurs continuent d'explorer de nouveaux schémas puissants, les bibliothèques FHE peuvent permettre à un plus grand nombre de développeurs d'intégrer la FHE.

Prenons l'exemple des contrats intelligents FHE. Bien qu'il puisse être difficile de choisir parmi différentes bibliothèques de FHE, cela devient plus facile lorsque nous parlons de FHE onchain car il n'y a que quelques langages de programmation dominants dans le Web3.

Par exemple, fhEVM de Zama intègre la bibliothèque open source TFHE-rs de Zama dans un EVM typique, exposant les opérations homomorphes sous forme de contrats précompilés. Permettre aux développeurs d'utiliser des données cryptées dans leurs contrats, sans modifier les outils de compilation.

Pour d'autres scénarios spécifiques, d'autres infrastructures peuvent être nécessaires. Par exemple, la bibliothèque TFHE écrite en C++ n'est pas aussi bien entretenue que la version Rust. Bien que TFHE-rs puisse prendre en charge les exportations pour C/C++, si les développeurs C++ veulent une meilleure compatibilité et de meilleures performances, ils doivent écrire leur propre version de la bibliothèque TFHE.

Enfin, l'une des principales raisons de l'absence d'infrastructure FHE sur le marché est que nous ne disposons pas de moyens efficaces pour construire des FHE-RAM. Une solution possible consiste à travailler sur un FHE-EVM sans certains opcodes.

Décryptage sécurisé des seuils

Défi : Décryptage de seuil non sécurisé/centralisé

Tout système d'état confidentiel et partagé repose sur une clé de cryptage/décryptage. Aucune partie n'étant digne de confiance, la clé de décryptage est répartie entre les participants au réseau.

L'un des aspects les plus difficiles de la FHE onchain (Threshold FHE) est l'élaboration d'un protocole de décryptage sécurisé et préformant. Il existe deux principaux goulets d'étranglement : (1) le calcul basé sur le FHE introduit une surcharge importante, nécessitant par conséquent des nœuds très performants, ce qui réduit intrinsèquement la taille potentielle de l'ensemble de validateurs (2) l'augmentation du nombre de nœuds participant au protocole de décryptage entraîne une augmentation du temps de latence.

Pour l'instant, les protocoles FHE reposent sur une majorité honnête parmi les validateurs. Toutefois, comme indiqué ci-dessus, le protocole FHE à seuil implique un ensemble de validateurs plus restreint et donc une probabilité plus élevée de collusion et de comportement malveillant.

Que se passe-t-il si les nœuds de seuil sont de connivence ? Ils seraient en mesure de contourner le protocole et de décrypter n'importe quoi, depuis les entrées de l'utilisateur jusqu'aux données de la chaîne. En outre, il est important de noter que le protocole de décryptage peut se produire de manière indétectable dans les systèmes actuels ("attaque silencieuse").

Solution : Décryptage à seuil amélioré ou MPC dynamique

Il existe quelques moyens de remédier aux insuffisances du décryptage par seuil. (1) activer un seuil n/2 qui rendrait plus difficile la collusion (2) exécuter le protocole de décryptage du seuil à l'intérieur d'un HSM (3) utiliser un réseau de décryptage du seuil basé sur un TEE et contrôlé par une chaîne décentralisée pour l'authentification, ce qui permettrait une gestion dynamique des clés.

Plutôt que d'utiliser le décryptage par seuil, il est possible d'utiliser le MPC. Le nouveau 2PC-MPC d'Odsy, le premier algorithme MPC non collusif et massivement décentralisé, est un exemple de protocole MPC qui pourrait être utilisé dans le cadre d'un FHE onchain.

Une autre approche pourrait consister à n'utiliser que la clé publique de l'utilisateur pour crypter les données. Les validateurs traitent ensuite les opérations homomorphes et les utilisateurs eux-mêmes peuvent décrypter le résultat si nécessaire. Bien que cela ne soit possible que pour des cas d'utilisation limités, nous pourrions éviter complètement l'hypothèse du seuil.

En résumé, la chaîne FHE a besoin d'une implémentation MPC efficace qui : (1) fonctionne même en présence d'acteurs malveillants (2) présente un temps de latence minimal (3) permet l'entrée de nœuds sans permission et de manière flexible.

Preuve de non-connaissance (ZKP) pour l'entrée de l'utilisateur et la partie calculatrice

Défi : vérifiabilité des données fournies par l'utilisateur + calcul :

Dans web2, lorsque nous demandons l'exécution d'une tâche informatique, nous faisons entièrement confiance à une entreprise donnée pour exécuter la tâche exactement comme elle l'a promis en coulisses. Dans le web3, le modèle est complètement inversé ; au lieu de se fier à la réputation d'une entreprise et de simplement croire qu'elle agira honnêtement, nous opérons maintenant dans un environnement sans confiance, ce qui signifie que les utilisateurs ne devraient pas avoir à faire confiance à qui que ce soit.

Si le FHE permet de traiter des données cryptées, il ne peut pas vérifier l'exactitude des entrées de l'utilisateur ou des calculs. Sans la possibilité de vérifier l'un ou l'autre, le FHE n'est guère utile dans le contexte de la blockchain.

Solution : ZKP pour les données de l'utilisateur + partie informatique :

Alors que la FHE permet à quiconque d'effectuer des calculs arbitraires sur des données cryptées, les ZKP permettent de prouver que quelque chose est vrai sans révéler l'information sous-jacente elle-même. Quel est donc le rapport entre ces deux éléments ?

La FHE et les ZKP s'articulent de trois manières principales :

1. L'utilisateur doit fournir une preuve que son texte chiffré d'entrée est bien formé. Cela signifie que le texte chiffré répond aux exigences du système de chiffrement et n'est pas une simple chaîne de données arbitraire.
2. L'utilisateur doit apporter la preuve que son texte en clair satisfait aux conditions d'une application donnée. Ex. amount_balance > amount_transfer
3. Le nœud de validation (ou partie informatique) doit prouver qu'il a correctement exécuté le calcul FHE. C'est ce que l'on appelle la "FHE vérifiable", qui peut être considérée comme analogue aux ZKP nécessaires pour les rollups.

Explorer plus avant les applications du ZKP :

1. ZKP du texte chiffré

La FHE repose sur une cryptographie basée sur des treillis, ce qui signifie que la construction de la primitive cryptographique fait appel à des treillis, qui sont sécurisés par le PQ (post-quantique). En revanche, les ZKP les plus répandus, tels que SNARKS, STARKS et Bulletproofs, ne reposent pas sur une cryptographie basée sur des treillis.

Pour prouver que le texte chiffré FHE de l'utilisateur est bien formé, nous devons montrer qu'il satisfait à une certaine équation matrice-vecteur avec des entrées provenant d'anneaux, et que les valeurs numériques de ces éléments sont faibles. Essentiellement, nous avons besoin d'un système de preuve de vérification rentable sur la chaîne, conçu pour traiter les relations basées sur des treillis, ce qui est un domaine de recherche ouvert.

1. ZKP de l'entrée en clair

Outre la preuve d'un texte chiffré bien formé, l'utilisateur doit prouver que son texte en clair satisfait aux exigences d'une application. Heureusement, contrairement à l'étape précédente, nous pouvons utiliser des SNARK généraux pour prouver la validité des entrées de l'utilisateur, ce qui permet aux développeurs d'utiliser les schémas, les bibliothèques et l'infrastructure ZKP existants.

Cependant, la difficulté réside dans le fait que nous devons "connecter" les deux systèmes de preuve. Connecter, c'est-à-dire que nous devons nous assurer que l'utilisateur a utilisé la même entrée pour les deux systèmes de preuve ; sinon, un utilisateur malveillant pourrait tricher avec le protocole. Une fois encore, il s'agit d'un exploit cryptographique incroyablement difficile et d'un domaine ouvert de recherche précoce.

Sunscreen a également jeté les bases de son compilateur ZKP qui prend en charge les Bulletproofs, car il se connecte plus facilement à SDLP. Des développements futurs sont en cours pour "lier" le compilateur FHE et ZKP.

Mind Network a été le premier à intégrer les ZKP pour garantir des entrées et des sorties sans confiance, tout en tirant parti de la FHE pour des calculs sécurisés.

1. ZKP du calcul correct

L'exécution de FHE sur le matériel existant est extrêmement inefficace et coûteuse. Comme nous l'avons déjà vu dans le cadre du trilemme de l'extensibilité, les réseaux dont les nœuds ont besoin de ressources plus importantes ne peuvent pas atteindre un niveau de décentralisation suffisant. Une solution possible pourrait être un processus appelé "FHE vérifiable", dans lequel la partie informatique (validateur) soumet un ZKP pour prouver l'exécution honnête des transactions.

Un premier prototype de FHE vérifiable peut être présenté dans le cadre d'un projet appelé SherLOCKED. Essentiellement, le calcul FHE est déchargé sur Bonsai de Risc ZERO qui effectue le calcul sur les données cryptées hors chaîne, renvoie le résultat avec un ZKP et met à jour l'état sur la chaîne.

Un exemple récent de l'exploitation d'un coprocesseur FHE est la démonstration de vente aux enchères onchain d'Aztec. Comme nous l'avons vu précédemment, les chaînes FHE existantes chiffrent l'état entier avec une clé de seuil, ce qui signifie que le système n'est aussi solide que son comité de seuil. À l'inverse, dans Aztec, les utilisateurs sont propriétaires de leurs données et ne sont donc pas soumis à un seuil de sécurité.

Enfin, il est important d'aborder la question de savoir où un développeur peut créer une application FHE en premier lieu. Les développeurs peuvent créer leurs applications sur un L1 alimenté par FHE, un rollup FHE ou sur n'importe quelle chaîne EVM et tirer parti d'un coprocesseur FHE. Chaque conception s'accompagne de son propre ensemble de compromis, mais nous sommes plus enclins à opter pour des rollups FHE bien conçus (inaugurés par Fhenix) ou des coprocesseurs FHE, car ils héritent de la sécurité d'Ethereum, entre autres avantages.

Récemment, l'équipe de Fhenix.io a démontré comment réaliser des preuves de fraude en utilisant la pile Arbitrum Nitro associée à la compilation de la logique FHE en WebAssembly.

Disponibilité des données (DA) Couche de FHE

Défi : Manque de personnalisation et de débit

Si le stockage a été banalisé dans le web2, il n'en va pas de même dans le web3. Étant donné que la méthode FHE permet d'obtenir des données volumineuses de plus de 10 000x, nous devons trouver un endroit où stocker les cryptogrammes FHE volumineux. Si tous les opérateurs de nœuds d'une couche DA donnée devaient télécharger et stocker les données de chaque chaîne FHE, seuls les opérateurs institutionnels seraient en mesure de répondre à la demande, ce qui risquerait d'entraîner une centralisation.

En ce qui concerne le débit, Celestia plafonne à 6,7mb/s, si nous voulons faire fonctionner une forme quelconque de FHEML, nous aurions besoin de plus de n GBs/sec. Selon des données récentes partagées par 1k(x), les couches DA existantes ne peuvent pas prendre en charge la FHE en raison de décisions de conception qui limitent le débit (intentionnellement).

Solution : Mise à l'échelle horizontale + personnalisation

Nous avons besoin d'une couche DA capable de prendre en charge l'évolutivité horizontale. Les architectures DA existantes propagent toutes les données à chaque nœud du réseau, ce qui constitue une contrainte majeure en termes d'évolutivité. Inversement, avec l'évolutivité horizontale, lorsque davantage de nœuds DA entrent dans le système, chaque nœud stocke 1/nième des données, ce qui améliore les performances et le coût au fur et à mesure que l'espace de blocs est rendu disponible.

Par ailleurs, compte tenu de la taille importante des données associées à l'ESF, il serait logique d'offrir aux développeurs un niveau plus élevé de personnalisation des seuils de codage de l'effacement. c'est-à-dire Quelle est la part du système DA avec laquelle vous vous sentez à l'aise en termes de garantie ? Qu'il s'agisse d'une pondération basée sur l'enjeu ou d'une pondération basée sur la décentralisation.

L'architecture d'EigenDA sert de base à ce que pourrait être une couche DA pour FHE. Ses propriétés de mise à l'échelle horizontale, de réduction des coûts structurels, de découplage de l'AD et du consensus, etc. permettent d'atteindre un niveau de mise à l'échelle qui pourrait un jour soutenir la FHE.

Enfin, une idée de haut niveau pourrait consister à créer des emplacements de stockage optimisés pour stocker les cryptogrammes FHE, étant donné que les cryptogrammes suivent un schéma d'encodage particulier et que des emplacements de stockage optimisés pourraient contribuer à une utilisation efficace de l'espace de stockage et à une récupération plus rapide.

Matériel de chiffrement entièrement homomorphe (FHE)

Défi : Matériel FHE peu performant

Dans la promotion des applications de cryptage entièrement homomorphique (FHE) sur la chaîne, un problème majeur est le temps de latence important dû à la surcharge de calcul, qui rend l'exécution du FHE impraticable sur n'importe quel matériel de traitement standard. Cette limitation est due à l'importance de l'interaction avec la mémoire en raison de l'énorme quantité de données que le processeur doit traiter. Outre les interactions avec la mémoire, les calculs polynomiaux complexes et les opérations de maintenance du texte chiffré, qui prennent du temps, entraînent également une surcharge importante.

Pour mieux comprendre l'état des accélérateurs FHE, nous devons découvrir l'espace de conception : Accélérateurs FHE spécifiques à une application et accélérateurs FHE généralisables.

Le nœud de la complexité de calcul et de la conception du matériel pour la FHE est toujours lié au nombre de multiplications nécessaires pour une application donnée, appelé "profondeur de l'opération homomorphique". Dans le cas d'une application spécifique, la profondeur est connue, de sorte que les paramètres du système et les calculs correspondants sont fixes. Par conséquent, la conception du matériel pour cette application spécifique sera plus facile et pourra généralement être optimisée pour obtenir de meilleures performances que la conception d'un accélérateur généralisable. Dans le cas général, où la FHE doit prendre en charge un nombre arbitraire de multiplications, le bootstrapping est nécessaire pour éliminer une partie du bruit accumulé dans les opérations homomorphes. L'amorçage est coûteux et nécessite des ressources matérielles considérables, notamment de la mémoire sur puce, de la bande passante et des calculs, ce qui signifie que la conception matérielle sera très différente de la conception spécifique à l'application. Par conséquent, bien que les travaux réalisés par les principaux acteurs de l'espace, notamment Intel, Duality, SRI, DARPA et bien d'autres, repoussent sans aucun doute les limites avec leurs conceptions basées sur les GPU et les ASIC, il se peut qu'ils ne soient pas applicables à l'échelle 1:1 pour prendre en charge les cas d'utilisation de la chaîne de blocs.

En ce qui concerne le coût de développement, la conception et la fabrication d'un matériel généralisable nécessitent plus de capitaux que celles d'un matériel spécifique à une application, mais sa flexibilité lui permet d'être utilisé dans un plus grand nombre d'applications. D'autre part, dans le cas d'une conception spécifique à une application, si les besoins de l'application évoluent et nécessitent la prise en charge d'un calcul homomorphique plus approfondi, le matériel spécifique à l'application devra être associé à certaines techniques logicielles, telles que le MPC, pour atteindre le même objectif que le matériel généralisable.

Il est important de noter qu'il est beaucoup plus difficile d'accélérer le FHE onchain que les cas d'utilisation spécifiques à une application (ex. FHEML), car il nécessite la capacité de traiter des calculs plus généraux plutôt qu'un ensemble plus spécialisé. A titre d'exemple, fhEVM devnet est contraint à un TPS à un chiffre pour le moment.

Étant donné que nous avons besoin d'un accélérateur FHE adapté à la blockchain, il convient également de se demander dans quelle mesure le travail peut être transféré du matériel ZKP au matériel FHE.

Il existe certains modules communs entre ZKP et FHE, tels que la transformation théorique des nombres (NTT) et les opérations polynomiales sous-jacentes. Cependant, la largeur de bit du NTT utilisée dans ces deux cas est différente. Dans le ZKP, le matériel doit prendre en charge une large gamme de largeurs de bits pour le NTT, telles que 64 bits et 256 bits, tandis que dans le FHE, les opérandes pour le NTT sont plus courts car ils sont représentés dans le système des nombres de résidus. Deuxièmement, le degré de NTT traité dans le ZKP est en général plus élevé que dans le cas du FHE. Pour ces deux raisons, il n'est pas trivial de concevoir un module NTT qui permette d'obtenir des performances satisfaisantes à la fois pour ZKP et FHE. Outre le NTT, il existe d'autres goulets d'étranglement informatiques dans l'EFS, tels que l'automorphisme, qui ne sont pas présents dans les ZKP. Une façon naïve de transférer le matériel ZKP à l'environnement FHE consiste à décharger la tâche de calcul NTT sur le matériel ZKP et à utiliser l'unité centrale ou un autre matériel pour gérer le reste du calcul dans le FHE.

Pour compléter les défis, le calcul sur des données cryptées avec FHE était 100 000 fois plus lent que sur des données en clair. Cependant, grâce aux nouveaux schémas de cryptage et aux développements récents du matériel FHE, les performances actuelles se sont considérablement améliorées et sont aujourd'hui environ 100 fois plus lentes que les données en clair.

Solutions :

1. Amélioration du matériel FHE

De nombreuses équipes construisent activement des accélérateurs de FHE, mais elles ne travaillent pas sur des accélérateurs de FHE spécifiques au calcul généralisable de la blockchain (c'est-à-dire. TFHE). Un exemple d'accélérateur matériel spécifique à la blockchain est FPT, un accélérateur FPGA à point fixe. FPT est le premier accélérateur matériel à exploiter fortement le bruit inhérent présent dans les calculs FHE en mettant en œuvre l'amorçage TFHE entièrement avec une arithmétique approximative en virgule fixe. Un autre projet qui pourrait être utile pour la FHE est BASALISC, une famille d'architecture d'accélérateurs matériels qui vise à accélérer considérablement les calculs de la FHE dans le nuage.

Comme indiqué précédemment, l'un des principaux goulets d'étranglement dans la conception du matériel FHE est l'interaction massive avec la mémoire. Pour contourner cet obstacle, une solution potentielle consiste à réduire autant que possible l'interaction avec la mémoire. Le traitement en mémoire (PIM) ou le calcul proche de la mémoire est probablement utile dans ce scénario. Le PIM est une solution prometteuse pour relever les défis du "mur de mémoire" pour les futurs systèmes informatiques, qui permet à la mémoire de servir à la fois les fonctions de calcul et de mémoire, promettant une rénovation radicale de la relation entre le calcul et la mémoire. Au cours de la dernière décennie, des progrès considérables ont été réalisés dans la conception de mémoires non volatiles à cette fin, telles que la mémoire vive résistive, la mémoire vive magnétique à transfert de spin et la mémoire à changement de phase. Grâce à cette mémoire spéciale, des travaux ont montré une amélioration significative des calculs dans le domaine de l'apprentissage automatique et du cryptage à clé publique basé sur des treillis.

1. Optimisation des logiciels et du matériel

Au cours des dernières années, les logiciels ont été reconnus comme un élément essentiel du processus d'accélération du matériel. Par exemple, les principaux accélérateurs FHE tels que F1 et CraterLake utilisent des compilateurs dans le cadre d'une approche hybride de co-conception logicielle et matérielle.

À mesure que l'espace progresse, nous pouvons nous attendre à ce que des compilateurs entièrement fonctionnels soient conçus conjointement avec des compilateurs FHE spécifiques à la blockchain. Les compilateurs FHE peuvent optimiser les programmes FHE sur la base du modèle de coût du schéma FHE correspondant. Ces compilateurs FHE pourraient être intégrés aux compilateurs d'accélérateurs FHE afin d'améliorer les performances de bout en bout en incorporant un modèle de coût au niveau matériel.

1. Mise en réseau des accélérateurs de FHE : Le passage de la mise à l'échelle à la sortie de l'échelle

Les efforts existants en matière d'accélération du matériel FHE se concentrent essentiellement sur la "mise à l'échelle", c'est-à-dire sur l'amélioration verticale d'un seul accélérateur. D'autre part, les sites "scale-out" se concentrent sur la connexion de plusieurs accélérateurs FHE en réseau horizontal, ce qui pourrait améliorer considérablement les performances, à l'instar de la génération de preuves en parallèle avec les ZKP.

L'une des principales difficultés de l'accélération FHE est le problème de l'inflation des données : Il s'agit de l'augmentation significative de la taille des données qui se produit pendant le cryptage et le calcul, ce qui pose des problèmes pour le déplacement efficace des données entre les mémoires sur puce et hors puce.

L'inflation des données constitue un défi important pour la connexion de plusieurs accélérateurs FHE par le biais d'une mise en réseau horizontale. Par conséquent, la co-conception du matériel et du réseau FHE constituera une orientation prometteuse de la recherche future. Il peut s'agir, par exemple, d'un routage adaptatif du réseau pour les accélérateurs FHE : Mise en œuvre d'un mécanisme de routage qui ajuste dynamiquement les chemins de données entre les accélérateurs FHE en fonction de la charge de calcul en temps réel et du trafic réseau. Cela garantirait des taux de transfert de données optimaux et une utilisation efficace des ressources.

Conclusion

La FHE va fondamentalement réimaginer la manière dont nous sécurisons les données à travers les plateformes, ouvrant la voie à une nouvelle ère de protection de la vie privée sans précédent. La construction d'un tel système nécessitera des avancées significatives non seulement dans le domaine de la FHE, mais aussi dans celui des ZKP et de la MPC.

Alors que nous nous aventurons dans cette nouvelle frontière, les efforts de collaboration entre les cryptographes, les ingénieurs en logiciel et les spécialistes en matériel seront impératifs. Sans oublier les législateurs, les politiciens, etc., car la conformité réglementaire est la seule voie vers l'adoption par le grand public.

En fin de compte, la FHE sera à l'avant-garde d'une vague transformatrice de souveraineté numérique, annonçant un avenir où la confidentialité et la sécurité des données ne s'excluent plus mutuellement mais s'unissent inextricablement.

Remerciements particuliers：

Merci à Mason Song (Mind Network), Guy Itzhaki (Fhenix), Leo Fan (Cysic), Kurt Pan, Xiang Xie (PADO), Nitanshu Lokhande (BananaHQ) pour leurs commentaires. Nous sommes impatients de découvrir le travail et les efforts impressionnants de ces personnes sur le terrain !

Clause de non-responsabilité：

1. Cet article est repris de[HashKey Capital]. Tous les droits d'auteur appartiennent à l'auteur original[Jeffrey Hu、Arnav Pagidyala]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.