Le FHE est la prochaine étape des ZK, selon les technologies de cryptographie
TechFlow SélectionTechFlow Sélection
Le FHE est la prochaine étape des ZK, selon les technologies de cryptographie
Les scénarios d'application et la mise en œuvre concrète constituent la percée permettant au chiffrement homomorphe entièrement homomorphe (FHE) de devenir une infrastructure blockchain.
Dédié à des analyses Web3 approfondiesRédaction : Zuo Ye
L'évolution des cryptomonnaies suit une trajectoire extrêmement claire : Bitcoin a créé les cryptomonnaies, Ethereum a inventé les blockchains publiques, Tether a introduit les stablecoins, et BitMEX a conçu le contrat perpétuel. Ces quatre innovations, telles des primitives cryptographiques, ont construit un marché d'un trillion de dollars, donné naissance à d'innombrables mythes de richesse fulgurante, ou encore alimenté le rêve, toujours vivace, d'une décentralisation radicale.
En revanche, la trajectoire du développement des technologies cryptographiques reste floue. Malgré toute une variété d'algorithmes de consensus et de conceptions ingénieuses, rien ne résiste face aux systèmes de mise en gage (staking) et de signatures multi-signatures (multisig), qui constituent véritablement les piliers soutenant l'infrastructure cryptographique. Par exemple, sans WBTC reposant sur un système de staking décentralisé, la majorité des solutions Layer 2 pour BTC ne pourraient exister. Babylon, avec son mécanisme de staking natif, explore précisément cette voie — une exploration valorisée à 70 millions de dollars.
Dans cet article, j'essaie d'esquisser une histoire du développement des technologies cryptographiques, distincte des simples évolutions techniques habituellement décrites dans l'industrie crypto. Prenons par exemple les relations entre FHE, ZK et MPC. D’un point de vue applicatif grossier, MPC intervient au démarrage, FHE peut être utilisé durant les calculs intermédiaires, tandis que ZK sert à produire une preuve finale. En termes chronologiques d’adoption, ZK a été le premier à se concrétiser, suivi par l’essor massif du concept de portefeuille AA (account abstraction), puis par la reconnaissance croissante de MPC comme solution technique, accélérant ainsi son développement. Seul FHE, bien qu’annoncé comme prometteur dès 2020, n’a commencé à prendre feu qu’en 2024.
MPC/FHE/ZKP
À la différence de ZK et MPC, FHE diffère même de tous les autres algorithmes cryptographiques actuels. Hormis FHE, toutes les techniques cryptographiques symétriques ou asymétriques visent à créer un « système de chiffrement difficile, voire impossible à casser », afin d’atteindre une sécurité absolue. Mais l’objectif de FHE est tout autre : permettre aux textes chiffrés de rester utiles. Autrement dit, le chiffrement et le déchiffrement sont cruciaux, mais il ne faut pas gaspiller les données entre ces deux étapes.
Théorie mature, adoption Web2 avant Web3
FHE est une technologie fondamentale dont l’exploration théorique est déjà achevée au niveau académique. Les géants du Web2 y ont fortement contribué : Microsoft, Intel, IBM, ainsi que Duality soutenu par DARPA, travaillent activement sur l’adaptation logicielle et matérielle, ainsi que sur les outils de développement.
Bonne nouvelle : même les géants du Web2 ignorent encore quoi faire de FHE. Le Web3 n’est donc pas trop en retard pour commencer. Mauvaise nouvelle : l’adaptation de FHE au Web3 est quasi inexistante. Ni Bitcoin ni Ethereum ne peuvent nativement supporter les algorithmes FHE. Bien qu’Ethereum se définisse comme « l’ordinateur mondial », effectuer des calculs FHE dessus pourrait bien durer jusqu’à la fin du monde.
Nous nous concentrons ici sur les explorations du Web3, mais gardons à l’esprit que les géants du Web2 s’intéressent vivement à FHE et ont déjà accompli un travail fondamental considérable.
Cela s’explique par le fait que Vitalik a centré ses efforts sur ZK entre 2020 et 2024.
Permettez-moi une brève explication sur le succès de ZK : après qu’Ethereum a adopté la voie du scaling via Rollup, la fonction de compression d’état de ZK réduit drastiquement la quantité de données transmises de L2 vers L1, ce qui représente une valeur économique immense. Bien sûr, cela reste théorique. Des problèmes émergents comme la fragmentation des L2, les questions liées aux séquenceurs, ou encore certaines pratiques abusives de frais prélevés par certains L2/Rollup, doivent être résolus par une évolution continue.
En résumé : Ethereum avait besoin de s’agrandir, a opté pour la voie des Layer 2, où ZK-Rollup et OP-Rollup rivalisent, instaurant un consensus sectoriel selon lequel OP dominerait à court terme, ZK à long terme, donnant naissance aux quatre géants ARB, OP, zkSync et StarkNet.
L’économie est la raison principale, voire unique, pour laquelle ZK a été accepté dans l’univers crypto, notamment dans l’écosystème Ethereum. Ainsi, plutôt que de détailler ici les caractéristiques techniques de FHE, je vais m’attacher à examiner dans quelle mesure FHE peut améliorer l’efficacité du Web3 ou en réduire les coûts. Réduction des coûts ou gain d’efficacité : l’un des deux doit être atteint.
Bref historique et avancées de FHE
Commençons par distinguer chiffrement homomorphe et chiffrement pleinement homomorphe (FHE). Stricto sensu, FHE est un cas particulier du premier. Un chiffrement homomorphe signifie que « réaliser une addition ou une multiplication sur des textes chiffrés équivaut à faire la même opération sur les textes en clair », soit :
Ici, c et E(c), d et E(d) peuvent être considérés comme équivalents. Toutefois, deux difficultés majeures existent :
-
L’égalité entre texte en clair et chiffré repose sur l’ajout de bruit au texte clair avant chiffrement. Si ce bruit devient trop important, les calculs échouent. La maîtrise du bruit via divers algorithmes est donc essentielle.
-
Les coûts computationnels des additions et multiplications sont énormes : les calculs sur textes chiffrés peuvent être 10 000 à 1 million de fois plus lourds que sur textes en clair. Seul un chiffrement permettant un nombre illimité d’additions et de multiplications peut être qualifié de pleinement homomorphe. Néanmoins, chaque type de chiffrement homomorphe possède sa propre valeur dans des domaines spécifiques. Selon leur degré d’accomplissement, on peut les classer ainsi :
-
Chiffrement partiellement homomorphe (PHE) : autorise uniquement un ensemble limité d’opérations, comme l’addition ou la multiplication. Chiffrement partiellement homomorphe (SHE) : autorise un nombre limité d’additions et de multiplications.
-
Chiffrement pleinement homomorphe (FHE) : autorise un nombre illimité d’additions et de multiplications, permettant ainsi des calculs arbitraires sur données chiffrées.
L’histoire de FHE remonte à 2009, lorsque Craig Gentry proposa pour la première fois un algorithme FHE basé sur lesréseaux idéaux. Un réseau idéal est une structure mathématique permettant de définir un ensemble de points dans un espace multidimensionnel, soumis à des relations linéaires spécifiques.
Dans le schéma de Gentry, les réseaux idéaux servent à représenter les clés et les données chiffrées, permettant ainsi de manipuler les données tout en préservant la confidentialité. La technique du bootstrapping (« auto-amorçage ») permet de réduire le bruit accumulé. On peut l’imaginer comme « s’attraper par ses lacets pour se retourner soi-même ». Concrètement, on re-chiffre le texte chiffré afin de réduire le bruit tout en maintenant la sécurité, rendant ainsi des calculs complexes possibles.
(Le bootstrapping est une avancée clé pour la viabilité pratique de FHE, mais nous n’entrerons pas davantage dans les détails mathématiques.)
Cet algorithme fut un jalon majeur, prouvant pour la première fois la faisabilité technique de FHE. Cependant, son coût était prohibitif : une seule opération pouvait prendre trente minutes, le rendant totalement impraticable.
Une fois le passage du zéro à un accompli, il ne restait plus qu’à industrialiser la solution. Cela impliquait de concevoir différents algorithmes selon diverses hypothèses mathématiques. Outre les réseaux idéaux, d’autres hypothèses comme LWE (Learning With Errors) et ses variantes sont aujourd’hui les plus couramment utilisées.
En 2012, Zvika Brakerski, Craig Gentry et Vinod Vaikuntanathan proposèrent le schéma BGV, l’une des secondes générations de FHE. Sa contribution majeure fut la technique de conversion de module, qui contrôle efficacement l’accumulation de bruit lors des opérations homomorphes, permettant ainsi la construction de FHE dits « nivelés » (Leveled FHE), capables d’exécuter des calculs homomorphes à profondeur fixée.
Des schémas similaires incluent BFV et CKKS. Ce dernier, capable de supporter les calculs sur nombres flottants, augmente encore la demande en puissance de calcul, nécessitant des solutions meilleures.
Enfin, mentionnons TFHE et FHEW, surtout TFHE, l’algorithme privilégié par Zama. Présentons-le brièvement : le problème du bruit dans FHE peut être atténué par le bootstrapping, initialement introduit par Gentry. TFHE permet un bootstrapping très efficace, tout en garantissant la précision, ce qui lui donne de bonnes synergies avec le domaine blockchain.
Nous nous arrêterons là dans la description des différents schémas. Leur différence ne tient pas à une supériorité intrinsèque, mais plutôt à leurs usages respectifs. Tous nécessitent néanmoins un support logiciel et matériel puissant. Même TFHE exige une résolution matérielle pour une application à grande échelle. Impossible donc d’emprunter la voie empruntée par ZK : « d’abord algorithmes et logiciels, puis matériel et modularité ». Avec FHE, hardware et software doivent évoluer conjointement dès le départ, du moins dans le domaine crypto.
Web2 OpenFHE vs Web3 Zama
Comme mentionné, les géants du Web2 explorent activement FHE et ont produit des résultats concrets. Résumons-les ici, puis introduisons les applications potentielles dans le Web3.
Pour aller à l’essentiel : IBM a développé la bibliothèque Helib, supportant principalement BGV et CKKS. Microsoft propose SEAL, axé sur CKKS et BFV. Notons que Song Yongsoo, co-auteur de CKKS, a participé à la conception de SEAL. OpenFHE, quant à lui, est le plus complet : développé par Duality (soutenu par DARPA), il supporte aujourd’hui BGV, BFV, CKKS, TFHE et FHEW, probablement la bibliothèque FHE la plus complète disponible sur le marché.
OpenFHE a également exploré des collaborations avec les bibliothèques d’accélération CPU d’Intel, et peut invoquer les interfaces CUDA de NVIDIA pour bénéficier d’un accélération GPU. Toutefois, le dernier support CUDA pour FHE date de 2018 ; aucune mise à jour récente n’a été trouvée. Merci de me corriger si nécessaire.
OpenFHE supporte C++ et Python, et développe progressivement une API Rust. Il vise à offrir modularité simple, complète et multiplateforme. Pour les développeurs Web2, c’est la solution plug-and-play la plus accessible.
Pour les développeurs Web3, la difficulté monte d’un cran.
Confinés par des capacités de calcul faibles, la plupart des blockchains publiques ne peuvent exécuter les algorithmes FHE. De plus, les écosystèmes Bitcoin et Ethereum manquent actuellement de « demande économique » pour FHE. Rappelons-le : ce fut la nécessité de transmettre efficacement des données de L2 vers L1 qui a permis à ZK de s’imposer. Ne forçons pas FHE là où il n’y a pas de besoin réel. Ce serait frapper un clou avec un marteau sans raison, augmentant inutilement les coûts d’adoption.
Principe de FHE + EVM
Nous explorerons plus tard les obstacles rencontrés et les scénarios possibles. Pour l’instant, donnons un peu confiance aux développeurs Web3.
En 2024, Zama a levé le plus gros financement lié à FHE dans le secteur crypto : 73 millions de dollars dirigés par Multicoin. Zama dispose actuellement d’une bibliothèque basée sur TFHE, et développe fhEVM, permettant de construire des chaînes compatibles EVM dotées de fonctions FHE.
Ensuite, vient la question de l’efficacité, qui ne peut être résolue que par une coopération logicielle et matérielle. Premièrement, l’EVM ne peut pas exécuter directement des contrats FHE, mais cela ne contredit pas l’approche de Zama. Ce dernier construit sa propre chaîne, intégrant nativement FHE. Par exemple, Shiba Inu envisage de construire une couche 3 basée sur Zama. Créer une nouvelle chaîne compatible FHE n’est pas difficile. Le vrai défi réside dans la capacité native de l’EVM d’Ethereum à déployer des contrats FHE, ce qui nécessite un support via les Opcode d’Ethereum. Bonne nouvelle : Fair Math et OpenFHE organisent le concours FHERMA, encourageant les développeurs à modifier les Opcode de l’EVM, explorant activement cette convergence.
Deuxièmement, l’accélération matérielle. Même si Solana ou d'autres blockchains hautes performances supportaient nativement les contrats FHE, elles ralentiraient gravement leurs nœuds. Les solutions matérielles natives incluent le 3PU™ (Privacy Protection Processing Unit) de Chain Reaction, une solution ASIC. Zama ou Inco explorent aussi des accélérations matérielles. Actuellement, Zama atteint environ 5 TPS, Inco environ 10 TPS. Inco estime que grâce à des FPGA, on pourrait atteindre 100 à 1000 TPS.
Toutefois, inutile de trop s’alarmer sur la vitesse. Les solutions d’accélération matérielle existantes pour ZK peuvent théoriquement être adaptées à FHE. Nous n’insisterons donc pas excessivement sur la vitesse dans la suite, mais concentrerons nos efforts sur la recherche de cas d’usage et la compatibilité EVM.
Dark pools en berne, avenir prometteur pour FHE × Crypto
Multicoin, en investissant dans Zama, a affirmé que ZKP appartient au passé, et que l’avenir sera à FHE. Que cette vision se réalise ou non, la réalité reste ardue. Après Zama, Inco Network et Fhenix forment un alliance silencieuse autour de l’écosystème fhEVM, chacun ayant des orientations différentes mais une trajectoire similaire : fusionner FHE et l’écosystème EVM.
Mieux vaut tard que jamais, commençons par une douche froide.
2024 pourrait marquer l’année forte de FHE, mais Elusiv, lancé en 2022, a cessé ses activités. Initialement un protocole de « dark pool » sur Solana, son dépôt de code et sa documentation ont été supprimés.
Au final, FHE, même s’il constitue un composant technique, doit être combiné avec d’autres technologies comme MPC ou ZKP. Ce que nous devons évaluer, c’est dans quelle mesure FHE peut transformer les paradigmes actuels de la blockchain.
Reconnaissons-le : penser que FHE renforce la confidentialité, donc a de la valeur économique, est une vision erronée. D’après l’expérience passée, les utilisateurs Web3 ou sur chaîne ne se soucient guère de la vie privée, sauf quand celle-ci apporte un avantage économique. Par exemple, les hackers utilisent Tornado Cash pour cacher leurs fonds volés, alors que les utilisateurs ordinaires préfèrent Uniswap, car Tornado Cash impose des coûts temporels ou financiers supplémentaires.
Le coût de chiffrement de FHE aggrave encore l’inefficacité inhérente aux blockchains. La confidentialité ne deviendra populaire que si ce coût élevé génère des bénéfices nettement supérieurs, par exemple dans l’émission et le trading d’obligations RWA. En juin 2023, BOC International, via UBS, a émis pour des clients asiatiques-pacifiques des « billets structurés numériques sur blockchain » à Hong Kong. UBS a indiqué dans son communiqué que cela s’était fait sur Ethereum, mais curieusement, aucune adresse de contrat ou de distribution n’a été trouvée. Si quelqu’un la découvre, merci de compléter l’information.
Cet exemple illustre bien l’importance de FHE. Pour les clients institutionnels, l’utilisation de blockchains publiques est souhaitable, mais la divulgation totale des données n’est ni appropriée ni souhaitée. Dans ce cas, la capacité de FHE à afficher des données chiffrées tout en permettant des opérations directes (achat/vente) est plus adaptée que ZKP.
Pour les petits investisseurs individuels, FHE reste une infrastructure de base lointaine. Je peux citer quelques directions : lutte contre le MEV, transactions privées, réseaux plus sûrs, protection contre l’espionnage tiers… Mais aucun de ces besoins n’est prioritaire. Utiliser FHE ralentit actuellement le réseau. Disons franchement : l’heure de gloire de FHE n’a pas encore sonné.
En définitive, la confidentialité est un besoin mineur. En tant que service public, peu de gens acceptent de payer un supplément pour la vie privée. Nous devons trouver des scénarios où la propriété de FHE — la possibilité de calculer sur des données chiffrées — permet de réduire les coûts ou d’améliorer l’efficacité transactionnelle, créant ainsi une dynamique spontanée du marché. Par exemple, il existe plusieurs solutions anti-MEV, dont des nœuds centralisés suffisent parfois. FHE ne touche pas directement le cœur du problème.
Un autre problème est celui de l’efficacité computationnelle. Apparemment technique (accélération matérielle ou optimisation d’algorithmes), il reflète en réalité un manque de demande du marché. Sans pression concurrentielle, pas d’innovation. L’efficacité se gagne à la compétition. Prenons ZK : sous la pression d’une forte demande, les routes SNARK et STARK s’affrontent, chaque Rollup ZK innove frénétiquement sur les langages et la compatibilité. Sous l’effet de l’argent chaud, ZK progresse à pas de géant.
Les cas d’usage et la mise en œuvre concrète sont la brèche par laquelle FHE peut devenir une infrastructure blockchain. Sans franchir ce seuil, FHE restera marginal, et les projets ne feront que gratter les bords, chacun dans son petit coin.
D’après les pratiques de Zama et ses alliés, un consensus émerge : construire de nouvelles chaînes en dehors d’Ethereum, en réutilisant des composants comme ERC-20, formant ainsi des chaînes FHE L1/L2 connectées à Ethereum. Avantage : tester rapidement, construire des composants de base. Inconvénient : si l’EVM d’Ethereum ne supporte pas nativement FHE, ces solutions resteront dans une position inconfortable.
Zama en est conscient. Outre ses bibliothèques, il a lancé l’organisation FHE.org et sponsorise des conférences, afin de transformer davantage de résultats académiques en applications industrielles.
Inco Network vise à devenir une « couche universelle de calcul privé », une sorte de prestataire de calcul externalisé. Basé sur Zama, il a construit un réseau FHE EVM L1. Une exploration intéressante est sa collaboration avec le protocole de messagerie inter-chaînes Hyperlane : un mécanisme de jeu sur une autre chaîne EVM peut être déployé sur Inco. Quand le jeu requiert un calcul FHE, Hyperlane appelle la puissance de calcul d’Inco, puis ne ramène que le résultat à la chaîne d’origine.
Pour que ce scénario fonctionne, il faut que les chaînes EVM fassent confiance à la réputation d’Inco, et qu’Inco dispose d’une puissance de calcul suffisante. Dans les jeux blockchain, aux besoins de haute concurrence et faible latence, le défi est considérable.
Plus largement, certains zkVM pourraient aussi jouer le rôle de fournisseur de calcul FHE. Par exemple, RISC Zero possède déjà cette capacité. La prochaine collision entre produits ZK et FHE pourrait générer de nouvelles étincelles.
Encore plus près d’Ethereum, certains projets veulent devenir une partie intégrante d’Ethereum. Si Inco utilise Zama pour créer un L1, Fhenix veut utiliser Zama pour créer un L2 EVM. Le projet est encore en cours, avec de nombreuses ambitions. On ignore encore quel produit final en sortira, probablement un L2 axé sur les capacités FHE.
Ajoutons aussi le concours FHERMA mentionné plus haut. Les lecteurs experts en développement Ethereum peuvent y participer, aidant à l’adoption de FHE tout en gagnant des prix.
Enfin, citons Sunscreen et Mind Network, deux projets atypiques. Sunscreen, piloté seul par Ravital, cherche à créer un compilateur adapté à FHE avec l’algorithme BFV, mais reste en phase expérimentale, loin d’une utilisation pratique.
Mind Network, quant à lui, explore principalement la combinaison de FHE avec des cas existants, comme le re-staking, mais la mise en œuvre concrète reste à prouver.
Enfin, revenons au début de cette section : Elusiv s’est rebaptisé Arcium, a levé de nouveaux fonds, et s’est repositionné sur une solution de « FHE parallèle », visant à améliorer l’efficacité d’exécution de FHE.
Conclusion
Cet article semble traiter de la théorie et de la pratique de FHE, mais en filigrane, il s’agit de clarifier l’histoire propre du développement des technologies cryptographiques, qui ne coïncide pas entièrement avec les technologies utilisées en crypto-monnaie. ZKP et FHE ont de nombreux points communs, notamment leur objectif de préserver la confidentialité tout en maintenant la transparence de la blockchain. La solution ZKP vise à réduire le coût économique des interactions entre L2 et L1, tandis que FHE cherche encore son meilleur scénario.
Typologie des solutions
La route est longue et tortueuse, FHE poursuit sa quête. On peut classer les approches selon leur proximité avec Ethereum :
-
Type 1 : Royaume indépendant, dialogue avec Ethereum. Représenté par Zama, Fhenix, Inco Network. Fournissent des briques de base, encouragent la création autonome de L1/L2 FHE, adapté à des niches spécifiques.
-
Type 2 : Extension externe, intégration à Ethereum. Représenté par Fair Math, Mind Network. Garde une certaine indépendance, mais cherche une fusion plus profonde avec Ethereum.
-
Type 3 : Coévolution, transformation d’Ethereum. Si Ethereum ne supporte pas nativement FHE, il faudra explorer des modifications au niveau contrat, diffusant les fonctions FHE sur toutes les chaînes compatibles EVM. Aucune solution pleinement conforme à ce type n’existe encore.
Contrairement à ZK, qui n’a vu l’émergence de solutions « one-click chain launch » et d’accélération matérielle qu’en phase tardive, FHE marche sur les épaules du géant ZK. Créer une chaîne FHE est peut-être aujourd’hui la chose la plus facile. Mais établir un lien solide avec Ethereum reste le défi le plus ardu.
Trois questions quotidiennes pour situer FHE dans le monde blockchain :
-
Quel scénario exige impérativement le chiffrement, excluant l’usage de texte en clair ?
-
Quel scénario nécessite spécifiquement FHE, et non d’autres méthodes de chiffrement ?
-
Quel scénario rend l’utilisation de FHE agréable pour l’utilisateur, prêt à payer un prix plus élevé ?
À suivre. Je continuerai de surveiller FHE !
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
@zuoyeweb3
