Décoder le Saint-Graal : les défis et solutions du chiffrement homomorphe sur chaîne
TechFlow SélectionTechFlow Sélection
Décoder le Saint-Graal : les défis et solutions du chiffrement homomorphe sur chaîne
Le chiffrement homomorphe complet (FHE) est considéré comme « la sainte relique de la cryptographie », mais son utilisation actuelle est limitée par des contraintes de performance, d'expérience de développement et de sécurité.
Dédié à des analyses Web3 approfondiesAuteurs : Jeffrey Hu, Arnav Pagidyala
Points clés
• Le chiffrement homomorphe entièrement homomorphe (FHE) est surnommé « la sainte graal de la cryptographie », mais son application actuelle reste limitée par des contraintes de performance, d'expérience développeur et de sécurité.
• Comme illustré ci-dessus, pour construire un système sécurisé d'état partagé véritablement confidentiel, il est nécessaire de combiner le FHE avec les preuves à connaissance nulle (ZKPs) et le calcul multipartite sécurisé (MPC).
• Le FHE évolue rapidement ; le développement de nouveaux compilateurs, bibliothèques, matériels, ainsi que la recherche menée par des entreprises Web2 (Intel, Google, DARPA, etc.) accélèrent considérablement ses progrès.
• À mesure que le FHE et son écosystème maturent, nous anticipons que le « FHE vérifiable » deviendra la norme. Les applications décentralisées (DApps) ou les rollups pourraient choisir d’externaliser leurs calculs et leur vérification vers des coprocesseurs FHE.
• Une limitation fondamentale du FHE sur chaîne concerne la question « qui détient la clé de déchiffrement ». Le déchiffrement seuil (threshold decryption) et le MPC offrent des solutions, mais impliquent généralement des compromis entre performance et sécurité.
Introduction
La transparence des blockchains est un double tranchant. Bien que l'ouverture et l'observabilité soient attrayantes, elles constituent précisément ce qui freine l'adoption par les entreprises.
La confidentialité sur chaîne a été l'un des défis les plus ardus du domaine crypto ces dix dernières années. Bien que de nombreuses équipes construisent des systèmes basés sur les preuves à connaissance nulle (ZKP) pour assurer la confidentialité, ceux-ci ne permettent pas d’état chiffré partagé. En effet, ces solutions reposent sur une suite de fonctions ZKP, rendant impossible l’application de logique arbitraire à l’état courant. Cela signifie qu’il n’est pas possible d’utiliser uniquement les ZKP pour développer des applications d’état partagé chiffrées (comme Uniswap privé).
Toutefois, des percées technologiques récentes montrent que combiner ZKP et chiffrement homomorphe entièrement homomorphe (FHE) permettrait une finance décentralisée (DeFi) pleinement générique et chiffrée. Comment cela fonctionne-t-il ? Le FHE est un domaine émergent de la cryptographie permettant d’effectuer des calculs arbitraires sur des données chiffrées. Comme indiqué ci-dessus, les ZKP peuvent prouver l’intégrité des entrées utilisateur et des calculs, tandis que le FHE gère le calcul lui-même.
Bien que le FHE soit qualifié de « sainte graal de la cryptographie », nous chercherons ici à fournir une analyse objective de ce domaine, de ses différents défis et des solutions possibles. Ce rapport technique couvrira les sujets suivants relatifs au FHE sur chaîne :
1. Schémas, bibliothèques et compilateurs FHE
2. Déchiffrement seuil sécurisé
3. Preuves à connaissance nulle pour les entrées utilisateurs et les parties calculantes
4. Couche de disponibilité des données (DA) programmable et extensible
5. Matériel FHE
Schémas, bibliothèques et compilateurs FHE
Défi : Schémas, bibliothèques et compilateurs FHE émergents
Le goulot d’étranglement fondamental du FHE sur chaîne réside dans le retard pris par ses outils de développement et son infrastructure. Contrairement aux preuves à connaissance nulle (ZKP) ou au MPC, le FHE, développé depuis 2009 seulement, est moins mature.
Les principales limitations de l’expérience développeur en FHE sont :
• L’absence de langage frontal convivial permettant aux développeurs de coder sans maîtriser profondément la cryptographie sous-jacente.
• L’absence de compilateur FHE complet capable de gérer automatiquement toutes les tâches complexes (choix des paramètres, optimisations SIMD pour BGV/BFV, parallélisation).
• La lenteur actuelle des schémas FHE (notamment TFHE), environ 1000 fois plus lents que le calcul classique.
Pour bien comprendre la complexité d'intégration du FHE, examinons le parcours d’un développeur :
La première étape consiste à choisir un schéma FHE. Le tableau ci-dessous décrit les principaux schémas disponibles :
Comme indiqué dans ce tableau, les circuits booléens (FHEW et TFHE) offrent la vitesse de bootstrapping la plus rapide, évitent des choix de paramètres complexes et supportent tout type de calcul, mais sont relativement lents. BGV/BFV conviennent mieux aux applications DeFi générales grâce à leur efficacité en arithmétique haute précision, mais nécessitent de connaître à l’avance la profondeur du circuit pour configurer tous les paramètres. CKKS, quant à lui, supporte la multiplication homomorphe avec tolérance aux erreurs de précision, ce qui le rend adapté aux cas non exacts comme le machine learning.
En tant que développeur, le choix du schéma FHE est critique car il impacte toutes les autres décisions techniques et la performance future. Par ailleurs, plusieurs paramètres clés doivent être correctement configurés, notamment la taille du module et le degré du polynôme.
Passons maintenant aux bibliothèques. Le tableau suivant présente les fonctionnalités des bibliothèques FHE les plus utilisées aujourd’hui :
Cependant, ces bibliothèques ont des relations différentes selon les schémas FHE et les compilateurs, comme illustré ci-dessous :
Une fois le schéma FHE choisi, le développeur doit configurer les paramètres. Leur sélection correcte influence fortement la performance. Cette étape est difficile car elle exige une compréhension de l’algèbre abstraite, des opérations spécifiques au FHE (relinéarisation, changement de module) et des circuits arithmétiques ou binaires. Pour y parvenir efficacement, il faut comprendre conceptuellement comment ces paramètres affectent le schéma FHE.
À ce stade, le développeur peut se poser des questions telles que :
Quelle taille dois-je prévoir pour mon espace en clair ? Quel niveau de taille de chiffré puis-je accepter ? Où puis-je paralléliser mes calculs ? etc.
De plus, bien que le FHE supporte tout type de calcul, il oblige les développeurs à changer de paradigme. Par exemple, on ne peut pas écrire de branchement conditionnel (if-else) basé sur une variable, car celle-ci ne peut pas être comparée directement comme une donnée ordinaire. Il faut donc reformuler le code pour inclure toutes les conditions dans un calcul unique. De même, les boucles sont impossibles à écrire directement.
En résumé, intégrer le FHE dans une application est presque impossible pour un développeur non initié. Cela nécessitera des outils et une infrastructure significativement améliorés pour masquer cette complexité.
Solutions :
1. Compilateur FHE natif Web3
Des compilateurs FHE existent déjà, développés par Google ou Microsoft, mais ils :
• Ne sont pas optimisés pour la performance, ajoutant un surcoût de 1000x par rapport à l’écriture directe de circuits.
• Sont optimisés pour CKKS (machine learning), donc peu bénéfiques pour BFV/BGV nécessaires en DeFi.
• Ne sont pas conçus pour le Web3, manquant de compatibilité avec les ZKP, blockchains programmables, etc.
L’arrivée du compilateur Sunscreen change la donne. Il s’agit d’un compilateur natif Web3 offrant certaines des meilleures performances pour les opérations arithmétiques (ex. DeFi), sans besoin d’accélérateur matériel. Comme mentionné précédemment, le choix des paramètres est souvent la partie la plus délicate. Sunscreen automatise non seulement ce choix, mais aussi l’encodage des données, la gestion des clés, la re-linéarisation, le changement de module, la configuration des circuits et les opérations SIMD.
Avec les progrès technologiques, nous espérons voir non seulement Sunscreen, mais d’autres équipes développer leurs propres compilateurs capables de supporter davantage de langages avancés.
2. Nouvelles bibliothèques FHE
Alors que les chercheurs explorent continuellement de nouveaux schémas efficaces, les bibliothèques FHE peuvent aussi faciliter l’intégration pour davantage de développeurs.
Prenons l'exemple des contrats intelligents FHE. Bien que le choix entre différentes bibliothèques FHE puisse être difficile, ce choix devient plus simple en contexte Web3, où seuls quelques langages dominants sont utilisés.
Par exemple, fhEVM de Zama intègre la bibliothèque open source TFHE-rs dans un EVM classique, exposant les opérations homomorphes comme contrats précompilés. Ainsi, les développeurs peuvent utiliser des données chiffrées dans leurs contrats sans modifier leurs outils de compilation.
Pour d'autres cas d'usage, d'autres infrastructures peuvent être nécessaires. Par exemple, la bibliothèque TFHE en C++ est moins bien maintenue que sa version Rust. Bien que TFHE-rs supporte l'export C/C++, les développeurs C++ souhaitant de meilleures performances et compatibilité devront créer leur propre version.
Enfin, un obstacle majeur à l’infrastructure FHE est l’absence d’un moyen efficace de construire une FHE-RAM. Une piste possible serait la recherche autour d’un FHE-EVM privé de certains opcodes.
Déchiffrement seuil sécurisé
Défi : Déchiffrement seuil non sécurisé ou centralisé
Tout système d’état partagé confidentiel repose sur des clés de chiffrement et de déchiffrement. Comme aucune entité unique ne peut être fiable, la clé de déchiffrement est fragmentée entre les participants via le calcul multipartite sécurisé (MPC).
L’un des aspects les plus difficiles du FHE sur chaîne est la construction d’un protocole de déchiffrement seuil à la fois sécurisé et performant. Deux goulets d’étranglement principaux existent :
(1) Les calculs FHE introduisent un surcoût important, nécessitant des nœuds très performants, ce qui réduit naturellement la taille potentielle de l’ensemble des validateurs ;
(2) Le délai augmente avec le nombre de nœuds participant au protocole de déchiffrement.
À ce jour, les protocoles FHE supposent une majorité honnête parmi les validateurs. Or, comme vu précédemment, le FHE sur chaîne implique un petit ensemble de validateurs, augmentant ainsi le risque de collusion ou de comportements malveillants.
Que se passe-t-il si les nœuds seuil collaborent malicieusement ? Ils pourraient contourner le protocole et déchiffrer n’importe quoi, y compris toutes les données utilisateur. Pire encore, dans les systèmes actuels, le protocole de déchiffrement peut être exécuté discrètement (« attaque silencieuse »).
Solution : Amélioration du déchiffrement seuil ou MPC dynamique
Plusieurs approches peuvent résoudre les faiblesses du déchiffrement seuil :
(1) Activer un seuil à n/2, rendant la collusion plus difficile ;
(2) Exécuter le protocole de déchiffrement seuil dans un module de sécurité matériel (HSM) ;
(3) Utiliser un réseau de déchiffrement seuil basé sur des environnements d’exécution fiables (TEE), contrôlé par une chaîne décentralisée, permettant une gestion dynamique des clés.
Plutôt que d’utiliser le déchiffrement seuil, une alternative plus probable est le MPC. Un exemple remarquable d’algorithme MPC applicable au FHE sur chaîne est le nouveau 2PC-MPC d’Odsy, premier algorithme MPC non conspiratif et massivement décentralisé.
Autre approche : chiffrer les données avec la seule clé publique de l’utilisateur. Les validateurs traitent alors les opérations homomorphes, et l’utilisateur déchiffre lui-même les résultats si nécessaire. Bien que limité à certains cas d’usage, cela permet d’éviter complètement l’hypothèse de seuil.
En résumé, le FHE sur chaîne nécessite une implémentation MPC efficace, dotée des caractéristiques suivantes :
(1) Fonctionner même en présence d’acteurs malveillants ;
(2) Introduire un minimum de latence ;
(3) Permettre une participation ouverte et flexible des nœuds.
Preuves à connaissance nulle (ZKP) pour les entrées utilisateurs et la partie calculante
Défi : Vérifiabilité des entrées utilisateurs et des calculs
Dans le monde Web2, lorsque nous demandons l’exécution d’un calcul, nous faisons entièrement confiance à une entreprise pour le mener comme promis en coulisses. Dans le Web3, ce modèle est inversé. Nous ne reposons plus sur la réputation d’une entreprise, mais opérons dans un environnement sans confiance, où aucun tiers ne doit être cru.
Bien que le chiffrement homomorphe entièrement homomorphe (FHE) permette de traiter des données chiffrées, il ne peut pas vérifier la justesse des entrées ou des calculs. Sans vérification, le FHE aurait peu d'utilité dans le contexte blockchain.
Solution : ZKP pour les entrées utilisateurs et la partie calculante
Le FHE permet d’effectuer des calculs arbitraires sur des données chiffrées, tandis que les ZKP permettent de prouver quelque chose sans révéler l’information sous-jacente. Comment ces deux technologies interagissent-elles ?
Le FHE et les ZKP peuvent être combinés de trois façons clés :
1. L’utilisateur doit soumettre une preuve que son chiffré d’entrée est correctement formaté, c’est-à-dire conforme aux exigences du schéma, et non une chaîne de données arbitraire.
2. L’utilisateur doit prouver que ses données en clair satisfont les conditions de l’application. Ex. : solde du compte > montant transféré.
3. Les nœuds validateurs (partie calculante) doivent prouver avoir correctement exécuté le calcul FHE. C’est ce qu’on appelle le « FHE vérifiable », analogue aux ZKP requis dans les rollups.
Approfondissons l’application des ZKP :
1. ZKP pour les chiffrés
Le FHE repose sur la cryptographie basée sur les réseaux (lattice-based), impliquant des primitives utilisant des réseaux post-quantiques. En revanche, les ZKP populaires (SNARKs, STARKs, Bulletproofs) n’utilisent pas cette base.
Pour prouver qu’un chiffré FHE est valide, il faut démontrer qu’il satisfait une équation matrice-vecteur avec des éléments de bagues, et que ces valeurs sont petites. Fondamentalement, il nous faut un système de preuve efficace sur chaîne, conçu pour les relations basées sur les réseaux — un domaine de recherche encore ouvert.
2. ZKP pour les entrées en clair
Outre la validité du format, les utilisateurs doivent prouver que leurs données en clair respectent les règles applicatives. Heureusement, contrairement à l’étape précédente, on peut utiliser des SNARKs génériques, permettant aux développeurs d’exploiter les bibliothèques et infrastructures ZKP existantes.
Le défi réside dans la « connexion » entre les deux systèmes de preuve. Il faut garantir que les deux preuves utilisent les mêmes entrées. Sinon, un utilisateur malveillant pourrait tromper le protocole. Là encore, il s’agit d’un exploit cryptographique extrêmement difficile, encore en phase de recherche exploratoire.
Sunscreen a posé des bases importantes : son compilateur ZKP supporte Bulletproofs, car il s’intègre le plus facilement avec SDLP. La recherche sur la connexion entre compilateurs FHE et ZKP progresse également.
Mind Network est en pointe sur l’intégration des ZKP pour garantir une entrée/sortie sans confiance, tout en utilisant le FHE pour le calcul sécurisé.
3. ZKP pour la correction du calcul
Le FHE est extrêmement inefficace et coûteux sur le matériel actuel. Comme illustré par le dilemme de l’évolutivité, les réseaux exigeants en ressources ne peuvent atteindre un haut niveau de décentralisation. Une solution possible est le « FHE vérifiable », où la partie calculante (validateur) soumet un ZKP attestant de l’exécution honnête de la transaction.
Un prototype précoce de FHE vérifiable est illustré par SherLOCKED. Ici, le calcul FHE est chargé sur Risc ZERO Bonsai zkVM, qui traite les données chiffrées hors chaîne, renvoie un résultat accompagné d’un ZKP, et met à jour l’état sur chaîne.
Un exemple récent utilisant un coprocesseur FHE : la démo d’enchères sur chaîne d’Aztec. Comme discuté précédemment, les chaînes FHE existantes chiffrent tout l’état avec une clé seuil, rendant la sécurité dépendante du comité seuil. Au contraire, chez Aztec, chaque utilisateur contrôle ses données, éliminant ainsi l’hypothèse de sécurité seuil.
Enfin, il est important de savoir où les développeurs peuvent construire des applications FHE. Ils peuvent le faire sur une L1 FHE, un rollup FHE, ou sur toute chaîne EVM en utilisant un coprocesseur FHE. Chaque conception comporte des compromis, mais nous privilégions les rollups FHE bien conçus (pionniers : Fhenix) ou les coprocesseurs FHE, car ils héritent de la sécurité d’Ethereum et d’autres avantages.
Jusqu’à récemment, mettre en œuvre des preuves de fraude sur des données FHE était complexe, mais l’équipe de Fhenix.io a récemment montré comment utiliser la pile Arbitrum Nitro avec une logique FHE compilée en WebAssembly pour y parvenir.
Couche de disponibilité des données (DA) pour le FHE
Défi : Manque de personnalisation et de débit
Bien que le « stockage » soit devenu une commodité en Web2, ce n’est pas le cas en Web3. Compte tenu du gonflement des données FHE (plus de 10 000x), il faut déterminer où stocker ces volumineux chiffrés. Si chaque opérateur de nœud dans une couche DA doit télécharger et stocker toutes les données d’une chaîne FHE, seules des institutions pourront suivre, augmentant ainsi le risque de centralisation.
Concernant le débit, Celestia atteint au maximum 6,7 Mo/s. Pour exécuter du FHEML, nous aurions besoin de plusieurs Go/s. Selon les données récentes partagées par 1k(x), les architectures DA actuelles ne peuvent supporter le FHE en raison de choix de conception limitant volontairement le débit.
Solution : Évolutivité horizontale + personnalisation
Nous avons besoin d'une couche DA pouvant s'évoluer horizontalement. Les architectures DA actuelles diffusent toutes les données à chaque nœud, ce qui limite fortement l'évolutivité. À l’inverse, l’évolutivité horizontale signifie que, avec l’ajout de nœuds DA, la charge par nœud diminue, améliorant performance et coût.
De plus, étant donné la taille importante des données FHE, il est pertinent d’offrir aux développeurs un haut niveau de personnalisation des seuils de codage d’effacement (erasure coding). Autrement dit, quel niveau de garantie souhaitent-ils ? Basé sur la mise en jeu ou sur la décentralisation.
L’architecture EigenDA pourrait servir de base potentielle pour une couche DA adaptée au FHE. Ses propriétés — évolutivité horizontale, réduction structurelle des coûts, découplage DA/consensus — ouvrent la voie à une scalabilité compatible avec le FHE.
Enfin, une idée plus ambitieuse serait de concevoir des emplacements de stockage optimisés pour les chiffrés FHE, car ceux-ci suivent un schéma d’encodage spécifique. Des emplacements optimisés permettraient une utilisation efficace de l’espace et un accès plus rapide.
Matériel FHE
Défi : Matériel FHE à faible performance
Un obstacle majeur à l’adoption du FHE sur chaîne est le délai significatif causé par la surcharge computationnelle, rendant son exécution impraticable sur tout matériel standard. Cette limitation provient des nombreuses interactions avec la mémoire, dues au traitement de volumes de données massifs. Outre cela, les calculs polynomiaux complexes et les opérations coûteuses de maintenance des chiffrés ajoutent un surcoût important.
Pour comprendre l’état des accélérateurs FHE, examinons deux types de conceptions : les accélérateurs FHE spécialisés versus généralistes.
La complexité du calcul FHE et la conception matérielle dépendent toujours du nombre de multiplications requises par l’application, appelé « profondeur d’opération homomorphe ». Pour une application spécialisée, cette profondeur est connue, donc les paramètres et calculs sont fixes. La conception matérielle est alors plus simple et souvent plus performante qu’un design généraliste. En revanche, pour supporter des calculs arbitraires, il faut recourir au bootstrapping pour supprimer le bruit accumulé. Cette technique est coûteuse en ressources matérielles (mémoire, bande passante, calcul), rendant la conception très différente de celle d’un dispositif spécialisé. Bien que des acteurs majeurs comme Intel, Duality, SRI ou DARPA progressent dans les GPU et ASIC, leurs solutions ne sont pas directement transférables aux scénarios blockchain.
En termes de coût, le matériel généraliste demande plus de capital pour la conception et fabrication, mais sa flexibilité permet une utilisation large. À l’inverse, un matériel spécialisé, si l’application évolue vers des calculs plus profonds, devra combiner hardware et techniques logicielles (comme le MPC) pour atteindre les mêmes objectifs.
Notons que l’accélération du FHE sur chaîne est bien plus difficile que pour des cas spécialisés (ex. FHEML), car elle doit supporter des calculs généraux. Par exemple, le réseau de développement fhEVM est actuellement limité à quelques TPS.
Étant donné le besoin d’accélérateurs FHE adaptés aux blockchains, une autre question se pose : quelle est la transférabilité du matériel ZKP vers le FHE ?
ZKP et FHE partagent certains modules, comme la transformation de nombre théorique (NTT) et les opérations polynomiales. Toutefois, les largeurs de bits utilisées diffèrent. En ZKP, le matériel doit supporter plusieurs largeurs (64, 256 bits), tandis qu’en FHE, le système de restes chinois impose des opérandes plus courts. De plus, le degré NTT est généralement plus élevé en ZKP. Ces différences rendent difficile la conception d’un module NTT performant pour les deux. En outre, le FHE présente d’autres goulets (ex. automorphismes) absents en ZKP. Une approche possible est de charger les calculs NTT sur du matériel ZKP, et d’utiliser CPU ou autre matériel pour le reste du FHE.
Résumant ces défis, le calcul FHE sur données chiffrées était autrefois 100 000 fois plus lent que sur données claires. Grâce à de nouveaux schémas et progrès matériels, la performance actuelle n’est plus que 100 fois inférieure.
Solutions :
1. Amélioration du matériel FHE
De nombreuses équipes développent activement des accélérateurs FHE, mais peu se concentrent sur des accélérateurs généralistes adaptés aux blockchains (ex. TFHE). Un exemple est FPT, un accélérateur FPGA à virgule fixe. FPT est le premier accélérateur exploitant fortement le bruit inhérent au FHE, implémentant entièrement le bootstrapping TFHE via de l’arithmétique approximative. Un autre projet utile est BASALISC, une série d’architectures d’accélérateurs matériels visant à accélérer massivement le FHE dans le cloud.
Comme mentionné, un goulet majeur du FHE est l’interaction intensive avec la mémoire. Pour contourner cela, une solution potentielle est de minimiser ces interactions. Le calcul dans la mémoire (PIM) ou près de la mémoire (near memory computation) pourrait aider. Le PIM est une solution prometteuse contre le « mur mémoire », permettant à la mémoire d’assumer à la fois stockage et calcul. Ces dix dernières années ont vu des progrès majeurs dans les mémoires non volatiles (RRAM, MRAM, PCM), dont certaines recherches ont déjà montré d’importants gains en ML et cryptographie basée sur les réseaux.
2. Logiciel et matériel optimisés
Récemment, le logiciel est reconnu comme un composant clé de l’accélération matérielle. Des accélérateurs célèbres comme F1 ou CraterLake utilisent des compilateurs pour une conception conjointe logiciel/matériel hybride.
À mesure que le domaine évolue, nous pouvons espérer des compilateurs complets conçus conjointement avec des compilateurs FHE orientés blockchain. Ces derniers pourraient optimiser les programmes selon le modèle de coût du schéma FHE, et s’intégrer aux compilateurs d’accélérateurs FHE pour améliorer la performance bout-en-bout via des modèles de coût matériel.
3. Accélérateur réseau FHE : de l’évolutivité verticale à l’évolutivité horizontale
Les efforts actuels en accélération FHE se concentrent sur l’« évolutivité verticale » (amélioration d’un seul accélérateur). L’« évolutivité horizontale » consiste à connecter plusieurs accélérateurs FHE en réseau, ce qui pourrait grandement améliorer la performance, similaire à la génération parallèle de preuves ZKP.
Un obstacle majeur est le gonflement des données : l’augmentation significative de la taille durant le chiffrement et le calcul, posant des défis pour le transfert efficace entre mémoires internes et externes.
Ce gonflement constitue un défi sérieux pour la connexion réseau de plusieurs accélérateurs. Ainsi, la conception conjointe matériel/réseau sera une direction prometteuse pour la recherche future. Par exemple, un routage réseau adaptatif pour accélérateurs FHE : un mécanisme ajustant dynamiquement les chemins de données entre accélérateurs selon la charge de calcul et le trafic réseau, assurant ainsi un taux de transfert optimal et une utilisation efficace des ressources.
Conclusion
Le FHE va fondamentalement transformer notre manière de protéger les données sur toutes les plateformes, ouvrant la voie à une nouvelle ère inédite de confidentialité. Construire un tel système exigera des avancées majeures en FHE, preuves à connaissance nulle (ZKPs) et calcul multipartite sécurisé (MPC).
En entrant dans ce nouveau domaine, la collaboration entre cryptographes, ingénieurs logiciels et experts matériels sera essentielle. Sans parler des législateurs et régulateurs, car la conformité est la seule voie vers une adoption massive.
Au final, le FHE se tiendra à l’avant-garde de la révolution de la souveraineté numérique, annonçant un futur où confidentialité et sécurité des données ne seront plus antagonistes, mais indissociables.
Remerciements spéciaux
Merci infiniment à Mason Song (Mind Network), Guy Itzhaki (Fhenix), Leo Fan (Cysic), Kurt Pan, Xiang Xie (PADO), Nitanshu Lokhande (BananaHQ) pour leurs relectures. Nous encourageons vivement les lecteurs à découvrir les travaux impressionnants réalisés par ces personnes dans ce domaine !
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
