La voie de développement des crypto-monnaies est claire : Bitcoin a introduit la crypto-monnaie, Ethereum introduit les chaînes publiques, Tether a créé les stablecoins et BitMEX a introduit les contrats perpétuels, construisant ensemble un marché de mille milliards de dollars avec d’innombrables histoires de richesse et des rêves de décentralisation.
La trajectoire de la technologie cryptographique est moins claire. Divers algorithmes de consensus et des conceptions sophistiquées sont éclipsés par les systèmes de jalonnement et de multi-signatures, les véritables piliers des cryptosystèmes. Par exemple, sans jalonnement décentralisé, la plupart des solutions BTC L2 n’existeraient pas. L’exploration de 70 millions de dollars de Babylon sur le jalonnement autochtone illustre cette direction.
Cet article tente de décrire l’histoire du développement de la technologie cryptographique, distincte des divers changements technologiques dans l’industrie de la cryptographie, tels que la relation entre FHE, ZK et MPC. Du point de vue de l’application approximative, MPC est utilisé initialement, FHE pour les calculs intermédiaires et ZK pour la preuve finale. Chronologiquement, ZK a été le premier, suivi par la hausse des portefeuilles AA, puis MPC a attiré l’attention et accéléré le développement, tandis que FHE, prévu pour une hausse en 2020, n’a commencé à gagner du terrain qu’en 2024.
MPC/FHE/ZKP
FHE diffère de ZK, MPC et de tous les algorithmes de chiffrement actuels. Contrairement aux technologies de chiffrement symétriques ou asymétriques, qui visent à créer des systèmes « incassables » pour une sécurité absolue, FHE vise à rendre fonctionnelles les données cryptées. Le chiffrement et le déchiffrement sont importants, mais les données entre le chiffrement et le déchiffrement devraient également être utiles.
FHE est une technologie fondamentale dont l’exploration théorique est terminée, grâce aux contributions importantes de géants du Web2 comme Microsoft, Intel, IBM et Duality, soutenu par la DARPA, qui ont préparé des adaptations logicielles et matérielles et des outils de développement.
La bonne nouvelle, c’est que les géants du Web2 ne savent pas non plus exactement quoi faire avec FHE. À partir de maintenant, le Web3 n’est pas en retard. La mauvaise nouvelle, c’est que l’adaptation au Web3 est presque nulle. Bitcoin et Ethereum grand public ne peuvent pas nativement prendre en support les algorithmes FHE. Bien qu’Ethereum soit appelé l’ordinateur mondial, le calcul de FHE pourrait prendre une éternité.
Nous nous concentrons sur l’exploration du Web3, notant que les géants du Web2 sont friands de FHE et ont effectué un travail préparatoire approfondi.
En effet, de 2020 à 2024, Vitalik s’est concentré sur ZK.
Ici, j’explique brièvement mon attribution de la hausse de ZK. Après qu’Ethereum ait établi le chemin de mise à l’échelle Rollup, la fonction de compression d’état de ZK a considérablement réduit la taille des données de L2 à L1, offrant une énorme valeur économique. C’est théorique ; La fragmentation L2, les problèmes de séquenceur et les problèmes de frais d’utilisation sont de nouveaux défis que le développement devra résoudre.
En résumé, Ethereum doit évoluer, en établissant la voie de développement Layer 2. ZK/OP rollups sont en compétition, formant un consensus ZK OP à short terme et ZK à long terme, avec ARB, OP, zkSync et StarkNet émergeant comme des acteurs majeurs.
La valeur économique est cruciale pour l’acceptation de ZK dans l’univers de la cryptomonnaie, en particulier Ethereum. Par conséquent, les caractéristiques techniques de FHE ne seront pas détaillées ici. L’accent est mis sur l’examen des domaines dans lesquels l’HE peut améliorer l’efficacité du Web3 ou réduire les coûts opérationnels, soit en réduisant les coûts, soit en augmentant l’efficacité.
Histoire et réalisations du développement de FHE
Tout d’abord, faites la distinction entre le chiffrement homomorphe et le chiffrement homomorphe complet. Strictement parlant, le chiffrement homomorphe complet est un cas particulier. Le chiffrement homomorphe signifie que « l’addition ou la multiplication de textes chiffrés équivaut à l’addition ou à la multiplication de textes clairs ». Cette équivalence se heurte à deux défis :
Le développement du chiffrement homomorphe complet (FHE) remonte à 2009 lorsque Craig Gentry a proposé un algorithme entièrement homomorphe basé sur des réseaux idéaux, une structure mathématique permettant aux utilisateurs de définir un ensemble de points dans un espace multidimensionnel satisfaisant des relations linéaires spécifiques.
Le schéma de Gentry utilise des treillis idéaux pour représenter les clés et les données chiffrées, ce qui permet aux données chiffrées de fonctionner tout en préservant la confidentialité. L’amorçage réduit le bruit, c’est-à-dire le fait de « se tirer vers le haut par ses propres sangles ». En pratique, il s’agit de rechiffrer le texte chiffré FHE pour réduire le bruit tout en préservant la confidentialité et en prenant en charge des opérations complexes. (L’amorçage est crucial pour l’utilisation pratique de FHE, mais ne sera pas détaillé plus en détail.)
Cet algorithme est une étape importante, prouvant la faisabilité de FHE en matière d’ingénierie, mais avec des coûts énormes, nécessitant trente minutes pour une étape de calcul, ce qui le rend peu pratique.
Après avoir résolu le problème 0 à 1, l’étape suivante est la praticité à grande échelle, impliquant la conception d’algorithmes basés sur différentes hypothèses mathématiques. Outre les réseaux idéaux, le LWE (Learning with Errors) et ses variantes sont des schémas courants.
En 2012, Zvika Brakerski, Craig Gentry et Vinod Vaikuntanathan ont proposé le système BGV, un système FHE de deuxième génération. Sa principale contribution est la technologie de commutation de module, qui contrôle efficacement l’augmentation du bruit à partir d’opérations homomorphes et la construction d’une FHE nivelée pour des profondeurs de calcul données.
Des schémas similaires incluent BFV et CKKS, en particulier CKKS, qui prend en charge les opérations en virgule flottante mais augmente la consommation de ressources de calcul, ce qui nécessite de meilleures solutions.
Enfin, les schémas TFHE et FHEW, en particulier TFHE, l’algorithme préféré de Zama. En bref, le problème de bruit de FHE peut être réduit grâce à l’amorçage de Gentry. TFHE réalise un bootstrapping efficace avec une assurance de précision, bien adapté à l’intégration de la blockchain.
Nous nous arrêtons à l’introduction de divers régimes. Leurs différences ne concernent pas la supériorité, mais différents scénarios, nécessitant généralement un support logiciel et matériel robuste. Même le système TFHE doit résoudre des problèmes matériels pour des applications à grande échelle. FHE doit développer du matériel de manière synchrone dès le départ, au moins en cryptographie.
Web 2 OpenFHE vs Web3 Zama
Comme nous l’avons mentionné, les géants du Web2 explorent et obtiennent des résultats pratiques, résumés ici avec des scénarios d’application Web3.
Pour simplifier, IBM a contribué à la bibliothèque Helib, prenant principalement en charge BGV et CKKS. La bibliothèque SEAL de Microsoft prend en charge CKKS et BFV. Notamment, l’auteur de CKKS, Song Yongsoo, a participé à la conception et au développement de SEAL. OpenFHE est la plus complète, développée par Duality prise en charge par la DARPA, prenant en charge BGV, BFV, CKKS, TFHE et FHEW, peut-être la bibliothèque FHE la plus complète du marché.
OpenFHE a exploré la coopération avec la bibliothèque d’accélération CPU d’Intel et a utilisé l’interface CUDA de NVIDIA pour l’accélération GPU. Cependant, le dernier support de CUDA pour FHE s’est arrêté en 2018, sans aucune mise à jour trouvée. Les corrections sont les bienvenues en cas d’erreur.
OpenFHE prend en charge les langages C ++ et Python, avec l’API Rust en développement, visant à fournir des capacités modulaires et multiplateformes simples, complètes et multiplateformes. Pour les développeurs Web2, il s’agit de la solution prête à l’emploi la plus simple.
Pour les développeurs Web3, la difficulté augmente. Limitées par une faible puissance de calcul, la plupart des chaînes publiques ne peuvent pas support les algorithmes FHE. Les écosystèmes Bitcoin et Ethereum manquent actuellement de « demande économique » pour FHE. La demande d’une transmission de données L2->L1 efficace a inspiré l’atterrissage de l’algorithme ZK. FHE pour FHE, c’est comme frapper des clous avec un marteau, forcer une allumette, augmenter les coûts.
Principe de fonctionnement FHE+EVM
Les sections suivantes détailleront les difficultés actuelles et les scénarios d’atterrissage possibles, donnant principalement confiance aux développeurs Web3. En 2024, Zama a reçu le plus grand funding lié à FHE en cryptographie, dirigé par Multicoin, levant 73 millions de dollars. Zama dispose d’une bibliothèque d’algorithmes TFHE et fhEVM prenant en charge le développement de chaînes compatibles EVM compatibles FHE.
Les problèmes d’efficacité ne peuvent être résolus que par une coopération logicielle-matérielle. L’un des problèmes est qu’EVM ne peut pas exécuter directement les contrats FHE, ce qui n’entre pas en conflit avec la solution fhEVM de Zama. Zama a construit une chaîne intégrant nativement les fonctionnalités de FHE. Par exemple, Shiba Inu prévoit une chaîne de couche 3 basée sur la solution de Zama. La création d’une nouvelle chaîne prenant en charge FHE n’est pas difficile, mais permettre à Ethereum EVM de déployer des contrats FHE nécessite l’support Opcode de Ethereum. La bonne nouvelle est que Fair Math et OpenFHE ont co-organisé le concours FHERMA, encourageant les développeurs à réécrire l’opcode d’EVM et explorant les possibilités d’intégration.
Un autre problème est l’accélération matérielle. Les chaînes publiques hautes performances comme Solana prenant en charge nativement le déploiement de contrats FHE pourraient submerger leurs nœuds. Le matériel FHE natif comprend la solution 3PU™ (Privacy Protecting Processing Unit) de Chain Reaction. Zama et Inco explorent les possibilités d’accélération matérielle. Par exemple, le TPS actuel de Zama est d’environ 5, Inco atteint 10 TPS et Inco pense que l’accélération matérielle FPGA peut augmenter le TPS à 100-1000.
Les préoccupations liées à la vitesse n’ont pas besoin d’être excessives. Les solutions d’accélération matérielle ZK existantes peuvent s’adapter aux solutions FHE. Ainsi, les discussions ne porteront pas sur les problèmes de vitesse, mais se concentreront sur la recherche de scénarios et la résolution de la compatibilité EVM.
Lorsque Multicoin a dirigé l’investissement dans Zama, ils ont audacieusement proclamé que ZKP appartenait au passé et que FHE représentait l’avenir. Reste à savoir si cette prédiction se réalisera, car la réalité est souvent difficile. Après Zama, Inco Network et Fhenix ont formé une alliance cachée dans l’écosystème fhEVM, chacun se concentrant sur différents aspects mais travaillant généralement à l’intégration de FHE à l’écosystème EVM.
Le timing est la clé, alors commençons par une dose de réalisme.
2024 est peut-être une grande année pour FHE, mais Elusiv, qui a démarré en 2022, a déjà cessé ses activités. Elusiv était initialement un protocole « dark pool » sur Solana, mais maintenant son référentiel de code et sa documentation ont été supprimés.
En fin de compte, FHE, dans le cadre d’un composant technique, doit encore être utilisé aux côtés de technologies telles que MPC / ZKP. Nous devons examiner comment FHE peut changer le paradigme actuel de la blockchain.
Tout d’abord, il est essentiel de comprendre qu’il est inexact de penser simplement que l’HE améliorera la vie privée et aura donc une valeur économique. D’après les pratiques passées, les utilisateurs Web3 ou off-chain ne se soucient pas beaucoup de la vie privée à moins qu’elle ne fournisse une valeur économique. Par exemple, les pirates utilisent Tornado Cash pour cacher les fonds volés, tandis que les utilisateurs réguliers préfèrent Uniswap car l’utilisation de Tornado Cash entraîne des coûts supplémentaires en termes de temps ou d’économie.
Le coût de chiffrement de FHE pèse davantage sur l’efficacité off-chain déjà faible. La protection de la vie privée ne peut être promue à grande échelle que si ce coût apporte des avantages significatifs. Par exemple, l’émission et la négociation d’obligations dans le sens des actifs pondérés en fonction des risques. En juin 2023, BOC International a émis des « billets structurés numériques blockchain » par l’intermédiaire d’UBS à Hong Kong pour des clients d’Asie-Pacifique, prétendant utiliser Ethereum, mais l’adresse du contrat et l’adresse de distribution sont introuvables. Si quelqu’un peut le trouver, veuillez fournir l’information.
Cet exemple met en évidence l’importance de FHE. Les clients institutionnels ont besoin d’utiliser des blockchains publiques, mais ne veulent pas divulguer toutes les informations. Par conséquent, la fonction d’affichage du texte chiffré de FHE, qui peut être directement échangé, est plus appropriée que ZKP.
Pour les investisseurs particuliers particuliers, l’EH est encore une infrastructure sous-jacente relativement lointaine. Les cas d’utilisation potentiels incluent l’anti-MEV, les transactions privées, des réseaux plus sécurisés et la prévention de l’espionnage par des tiers. Cependant, il ne s’agit pas de besoins primaires, et l’utilisation de FHE ralentit effectivement le réseau. Franchement, le moment clé de la FHE n’est pas encore arrivé.
En fin de compte, la protection de la vie privée n’est pas une demande forte. Peu de gens sont prêts à payer plus cher pour la protection de la vie privée en tant que service public. Nous devons trouver des scénarios dans lesquels les fonctionnalités calculables des données chiffrées de FHE peuvent réduire les coûts ou améliorer l’efficacité des transactions, générant ainsi une dynamique de marché. Par exemple, il existe de nombreuses solutions anti-MEV, et les nœuds centralisés peuvent résoudre le problème. FHE n’aborde pas directement les points douloureux.
Un autre problème est l’efficacité informatique. À première vue, il s’agit d’un problème technique nécessitant une accélération matérielle ou une optimisation des algorithmes, mais fondamentalement, il s’agit d’un manque de demande du marché, sans incitation pour les parties prenantes du projet à se faire concurrence. L’efficacité informatique résulte de la concurrence. Par exemple, dans le cadre de la demande croissante du marché, les routes SNARK et STARK sont en concurrence, avec divers ZK Rollups qui se livrent une concurrence féroce, des langages de programmation à la compatibilité. Le développement de ZK a été rapide sous la pression de l’argent chaud.
Les scénarios d’application et la mise en œuvre sont les points de rupture pour que FHE devienne une infrastructure blockchain. Sans prendre cette mesure, FHE ne prendra jamais de l’ampleur dans l’industrie de la cryptographie, et les grands projets ne peuvent que bricoler dans leurs petits domaines.
D’après les pratiques de Zama et de ses partenaires, un consensus est de créer de nouvelles chaînes en dehors d’Ethereum et de réutiliser ERC-20 et d’autres composants et normes techniques pour former des chaînes FHE L1/L2 liées à Ethereum. Cette approche permet de tester et de construire rapidement les composants de base de FHE. L’inconvénient est que si Ethereum ne prend pas en support les algorithmes FHE, les solutions de chaîne externes seront toujours gênantes.
Zama reconnaît également ce problème. Outre les bibliothèques liées à la FHE susmentionnées, il a initié l’organisation FHE.org et parrainé des conférences connexes pour traduire davantage de réalisations académiques en applications d’ingénierie.
L’orientation de développement d’Inco Network est une « couche informatique universelle de confidentialité », essentiellement un modèle de fournisseur de services d’externalisation informatique. Il a construit un réseau FHE EVM L1 basé sur Zama. Une exploration intéressante est la coopération avec le protocole de messagerie cross-chain Hyperlane, qui peut déployer des mécanismes de jeu à partir d’une autre chaîne compatible EVM sur Inco. Lorsque le jeu nécessite un calcul FHE, Hyperlane appelle la puissance de calcul d’Inco et renvoie ensuite uniquement les résultats à la chaîne d’origine.
Pour réaliser de tels scénarios envisagés par Inco, les chaînes compatibles EVM doivent faire confiance à la crédibilité d’Inco, et la puissance de calcul d’Inco doit être suffisamment forte pour gérer les exigences de concurrence élevée et de faible latence des jeux blockchain, ce qui est très difficile.
En plus de cela, certaines zkVM peuvent également servir de fournisseurs d’externalisation informatique FHE. Par exemple, RISC Zero a cette capacité. La prochaine étape de la collision entre les produits ZK et FHE pourrait susciter d’autres idées.
En outre, certains projets visent à se rapprocher d’Ethereum ou à en faire partie. Inco peut utiliser la solution de Zama pour L1 et Fhenix peut utiliser la solution de Zama pour EVM L2. Actuellement, ils sont encore en développement, avec de nombreuses directions potentielles. On ne sait pas sur quel produit ils finiront par atterrir. Il peut s’agir d’une L2 axée sur les capacités FEH.
De plus, il y a le concours FHERMA mentionné plus haut. Les développeurs avertis d’Ethereum dans le public peuvent l’essayer, aidant FHE à atterrir tout en gagnant des bonus.
Il y a aussi des projets intrigants comme Sunscreen et Mind Network. Sunscreen, principalement exploité par Ravital, vise à développer un compilateur FHE approprié utilisant l’algorithme BFV mais reste en phase de test et d’expérimentation, loin d’une application pratique.
Enfin, Mind Network se concentre sur la combinaison de FHE avec des scénarios existants tels que le re-staking, mais il reste à voir comment cela sera réalisé.
En conclusion, Elusiv a maintenant été renommé Arcium et a reçu un nouveau funding, se transformant en une solution « FHE parallèle » pour améliorer l’efficacité d’exécution de FHE.
Cet article semble discuter de la théorie et de la pratique de la FHE, mais le thème sous-jacent est de clarifier l’histoire du développement de la technologie cryptographique. Ce n’est pas tout à fait la même chose que la technologie utilisée dans les crypto-monnaies. ZKP et FHE présentent de nombreuses similitudes, l’une d’entre elles étant leur effort pour maintenir la transparence de la blockchain tout en préservant la vie privée. ZKP vise à réduire les coûts économiques dans les interactions L2 <> L1, tandis que FHE est toujours à la recherche de son meilleur scénario d’application.
Classification de la solution :
Le chemin à parcourir est long et difficile. FHE poursuit son exploration. Sur la base de sa relation avec Ethereum, il peut être divisé en trois types :
Contrairement à ZK, qui n’a connu que le lancement pratique de chaînes et l’accélération matérielle dans les étapes ultérieures, FHE repose sur les épaules des géants de ZK. Créer une chaîne FHE est maintenant la tâche la plus simple, mais l’intégrer à Ethereum reste le plus difficile.
Réfléchissez quotidiennement à la future position de la FHE dans le monde de la blockchain :
La voie de développement des crypto-monnaies est claire : Bitcoin a introduit la crypto-monnaie, Ethereum introduit les chaînes publiques, Tether a créé les stablecoins et BitMEX a introduit les contrats perpétuels, construisant ensemble un marché de mille milliards de dollars avec d’innombrables histoires de richesse et des rêves de décentralisation.
La trajectoire de la technologie cryptographique est moins claire. Divers algorithmes de consensus et des conceptions sophistiquées sont éclipsés par les systèmes de jalonnement et de multi-signatures, les véritables piliers des cryptosystèmes. Par exemple, sans jalonnement décentralisé, la plupart des solutions BTC L2 n’existeraient pas. L’exploration de 70 millions de dollars de Babylon sur le jalonnement autochtone illustre cette direction.
Cet article tente de décrire l’histoire du développement de la technologie cryptographique, distincte des divers changements technologiques dans l’industrie de la cryptographie, tels que la relation entre FHE, ZK et MPC. Du point de vue de l’application approximative, MPC est utilisé initialement, FHE pour les calculs intermédiaires et ZK pour la preuve finale. Chronologiquement, ZK a été le premier, suivi par la hausse des portefeuilles AA, puis MPC a attiré l’attention et accéléré le développement, tandis que FHE, prévu pour une hausse en 2020, n’a commencé à gagner du terrain qu’en 2024.
MPC/FHE/ZKP
FHE diffère de ZK, MPC et de tous les algorithmes de chiffrement actuels. Contrairement aux technologies de chiffrement symétriques ou asymétriques, qui visent à créer des systèmes « incassables » pour une sécurité absolue, FHE vise à rendre fonctionnelles les données cryptées. Le chiffrement et le déchiffrement sont importants, mais les données entre le chiffrement et le déchiffrement devraient également être utiles.
FHE est une technologie fondamentale dont l’exploration théorique est terminée, grâce aux contributions importantes de géants du Web2 comme Microsoft, Intel, IBM et Duality, soutenu par la DARPA, qui ont préparé des adaptations logicielles et matérielles et des outils de développement.
La bonne nouvelle, c’est que les géants du Web2 ne savent pas non plus exactement quoi faire avec FHE. À partir de maintenant, le Web3 n’est pas en retard. La mauvaise nouvelle, c’est que l’adaptation au Web3 est presque nulle. Bitcoin et Ethereum grand public ne peuvent pas nativement prendre en support les algorithmes FHE. Bien qu’Ethereum soit appelé l’ordinateur mondial, le calcul de FHE pourrait prendre une éternité.
Nous nous concentrons sur l’exploration du Web3, notant que les géants du Web2 sont friands de FHE et ont effectué un travail préparatoire approfondi.
En effet, de 2020 à 2024, Vitalik s’est concentré sur ZK.
Ici, j’explique brièvement mon attribution de la hausse de ZK. Après qu’Ethereum ait établi le chemin de mise à l’échelle Rollup, la fonction de compression d’état de ZK a considérablement réduit la taille des données de L2 à L1, offrant une énorme valeur économique. C’est théorique ; La fragmentation L2, les problèmes de séquenceur et les problèmes de frais d’utilisation sont de nouveaux défis que le développement devra résoudre.
En résumé, Ethereum doit évoluer, en établissant la voie de développement Layer 2. ZK/OP rollups sont en compétition, formant un consensus ZK OP à short terme et ZK à long terme, avec ARB, OP, zkSync et StarkNet émergeant comme des acteurs majeurs.
La valeur économique est cruciale pour l’acceptation de ZK dans l’univers de la cryptomonnaie, en particulier Ethereum. Par conséquent, les caractéristiques techniques de FHE ne seront pas détaillées ici. L’accent est mis sur l’examen des domaines dans lesquels l’HE peut améliorer l’efficacité du Web3 ou réduire les coûts opérationnels, soit en réduisant les coûts, soit en augmentant l’efficacité.
Histoire et réalisations du développement de FHE
Tout d’abord, faites la distinction entre le chiffrement homomorphe et le chiffrement homomorphe complet. Strictement parlant, le chiffrement homomorphe complet est un cas particulier. Le chiffrement homomorphe signifie que « l’addition ou la multiplication de textes chiffrés équivaut à l’addition ou à la multiplication de textes clairs ». Cette équivalence se heurte à deux défis :
Le développement du chiffrement homomorphe complet (FHE) remonte à 2009 lorsque Craig Gentry a proposé un algorithme entièrement homomorphe basé sur des réseaux idéaux, une structure mathématique permettant aux utilisateurs de définir un ensemble de points dans un espace multidimensionnel satisfaisant des relations linéaires spécifiques.
Le schéma de Gentry utilise des treillis idéaux pour représenter les clés et les données chiffrées, ce qui permet aux données chiffrées de fonctionner tout en préservant la confidentialité. L’amorçage réduit le bruit, c’est-à-dire le fait de « se tirer vers le haut par ses propres sangles ». En pratique, il s’agit de rechiffrer le texte chiffré FHE pour réduire le bruit tout en préservant la confidentialité et en prenant en charge des opérations complexes. (L’amorçage est crucial pour l’utilisation pratique de FHE, mais ne sera pas détaillé plus en détail.)
Cet algorithme est une étape importante, prouvant la faisabilité de FHE en matière d’ingénierie, mais avec des coûts énormes, nécessitant trente minutes pour une étape de calcul, ce qui le rend peu pratique.
Après avoir résolu le problème 0 à 1, l’étape suivante est la praticité à grande échelle, impliquant la conception d’algorithmes basés sur différentes hypothèses mathématiques. Outre les réseaux idéaux, le LWE (Learning with Errors) et ses variantes sont des schémas courants.
En 2012, Zvika Brakerski, Craig Gentry et Vinod Vaikuntanathan ont proposé le système BGV, un système FHE de deuxième génération. Sa principale contribution est la technologie de commutation de module, qui contrôle efficacement l’augmentation du bruit à partir d’opérations homomorphes et la construction d’une FHE nivelée pour des profondeurs de calcul données.
Des schémas similaires incluent BFV et CKKS, en particulier CKKS, qui prend en charge les opérations en virgule flottante mais augmente la consommation de ressources de calcul, ce qui nécessite de meilleures solutions.
Enfin, les schémas TFHE et FHEW, en particulier TFHE, l’algorithme préféré de Zama. En bref, le problème de bruit de FHE peut être réduit grâce à l’amorçage de Gentry. TFHE réalise un bootstrapping efficace avec une assurance de précision, bien adapté à l’intégration de la blockchain.
Nous nous arrêtons à l’introduction de divers régimes. Leurs différences ne concernent pas la supériorité, mais différents scénarios, nécessitant généralement un support logiciel et matériel robuste. Même le système TFHE doit résoudre des problèmes matériels pour des applications à grande échelle. FHE doit développer du matériel de manière synchrone dès le départ, au moins en cryptographie.
Web 2 OpenFHE vs Web3 Zama
Comme nous l’avons mentionné, les géants du Web2 explorent et obtiennent des résultats pratiques, résumés ici avec des scénarios d’application Web3.
Pour simplifier, IBM a contribué à la bibliothèque Helib, prenant principalement en charge BGV et CKKS. La bibliothèque SEAL de Microsoft prend en charge CKKS et BFV. Notamment, l’auteur de CKKS, Song Yongsoo, a participé à la conception et au développement de SEAL. OpenFHE est la plus complète, développée par Duality prise en charge par la DARPA, prenant en charge BGV, BFV, CKKS, TFHE et FHEW, peut-être la bibliothèque FHE la plus complète du marché.
OpenFHE a exploré la coopération avec la bibliothèque d’accélération CPU d’Intel et a utilisé l’interface CUDA de NVIDIA pour l’accélération GPU. Cependant, le dernier support de CUDA pour FHE s’est arrêté en 2018, sans aucune mise à jour trouvée. Les corrections sont les bienvenues en cas d’erreur.
OpenFHE prend en charge les langages C ++ et Python, avec l’API Rust en développement, visant à fournir des capacités modulaires et multiplateformes simples, complètes et multiplateformes. Pour les développeurs Web2, il s’agit de la solution prête à l’emploi la plus simple.
Pour les développeurs Web3, la difficulté augmente. Limitées par une faible puissance de calcul, la plupart des chaînes publiques ne peuvent pas support les algorithmes FHE. Les écosystèmes Bitcoin et Ethereum manquent actuellement de « demande économique » pour FHE. La demande d’une transmission de données L2->L1 efficace a inspiré l’atterrissage de l’algorithme ZK. FHE pour FHE, c’est comme frapper des clous avec un marteau, forcer une allumette, augmenter les coûts.
Principe de fonctionnement FHE+EVM
Les sections suivantes détailleront les difficultés actuelles et les scénarios d’atterrissage possibles, donnant principalement confiance aux développeurs Web3. En 2024, Zama a reçu le plus grand funding lié à FHE en cryptographie, dirigé par Multicoin, levant 73 millions de dollars. Zama dispose d’une bibliothèque d’algorithmes TFHE et fhEVM prenant en charge le développement de chaînes compatibles EVM compatibles FHE.
Les problèmes d’efficacité ne peuvent être résolus que par une coopération logicielle-matérielle. L’un des problèmes est qu’EVM ne peut pas exécuter directement les contrats FHE, ce qui n’entre pas en conflit avec la solution fhEVM de Zama. Zama a construit une chaîne intégrant nativement les fonctionnalités de FHE. Par exemple, Shiba Inu prévoit une chaîne de couche 3 basée sur la solution de Zama. La création d’une nouvelle chaîne prenant en charge FHE n’est pas difficile, mais permettre à Ethereum EVM de déployer des contrats FHE nécessite l’support Opcode de Ethereum. La bonne nouvelle est que Fair Math et OpenFHE ont co-organisé le concours FHERMA, encourageant les développeurs à réécrire l’opcode d’EVM et explorant les possibilités d’intégration.
Un autre problème est l’accélération matérielle. Les chaînes publiques hautes performances comme Solana prenant en charge nativement le déploiement de contrats FHE pourraient submerger leurs nœuds. Le matériel FHE natif comprend la solution 3PU™ (Privacy Protecting Processing Unit) de Chain Reaction. Zama et Inco explorent les possibilités d’accélération matérielle. Par exemple, le TPS actuel de Zama est d’environ 5, Inco atteint 10 TPS et Inco pense que l’accélération matérielle FPGA peut augmenter le TPS à 100-1000.
Les préoccupations liées à la vitesse n’ont pas besoin d’être excessives. Les solutions d’accélération matérielle ZK existantes peuvent s’adapter aux solutions FHE. Ainsi, les discussions ne porteront pas sur les problèmes de vitesse, mais se concentreront sur la recherche de scénarios et la résolution de la compatibilité EVM.
Lorsque Multicoin a dirigé l’investissement dans Zama, ils ont audacieusement proclamé que ZKP appartenait au passé et que FHE représentait l’avenir. Reste à savoir si cette prédiction se réalisera, car la réalité est souvent difficile. Après Zama, Inco Network et Fhenix ont formé une alliance cachée dans l’écosystème fhEVM, chacun se concentrant sur différents aspects mais travaillant généralement à l’intégration de FHE à l’écosystème EVM.
Le timing est la clé, alors commençons par une dose de réalisme.
2024 est peut-être une grande année pour FHE, mais Elusiv, qui a démarré en 2022, a déjà cessé ses activités. Elusiv était initialement un protocole « dark pool » sur Solana, mais maintenant son référentiel de code et sa documentation ont été supprimés.
En fin de compte, FHE, dans le cadre d’un composant technique, doit encore être utilisé aux côtés de technologies telles que MPC / ZKP. Nous devons examiner comment FHE peut changer le paradigme actuel de la blockchain.
Tout d’abord, il est essentiel de comprendre qu’il est inexact de penser simplement que l’HE améliorera la vie privée et aura donc une valeur économique. D’après les pratiques passées, les utilisateurs Web3 ou off-chain ne se soucient pas beaucoup de la vie privée à moins qu’elle ne fournisse une valeur économique. Par exemple, les pirates utilisent Tornado Cash pour cacher les fonds volés, tandis que les utilisateurs réguliers préfèrent Uniswap car l’utilisation de Tornado Cash entraîne des coûts supplémentaires en termes de temps ou d’économie.
Le coût de chiffrement de FHE pèse davantage sur l’efficacité off-chain déjà faible. La protection de la vie privée ne peut être promue à grande échelle que si ce coût apporte des avantages significatifs. Par exemple, l’émission et la négociation d’obligations dans le sens des actifs pondérés en fonction des risques. En juin 2023, BOC International a émis des « billets structurés numériques blockchain » par l’intermédiaire d’UBS à Hong Kong pour des clients d’Asie-Pacifique, prétendant utiliser Ethereum, mais l’adresse du contrat et l’adresse de distribution sont introuvables. Si quelqu’un peut le trouver, veuillez fournir l’information.
Cet exemple met en évidence l’importance de FHE. Les clients institutionnels ont besoin d’utiliser des blockchains publiques, mais ne veulent pas divulguer toutes les informations. Par conséquent, la fonction d’affichage du texte chiffré de FHE, qui peut être directement échangé, est plus appropriée que ZKP.
Pour les investisseurs particuliers particuliers, l’EH est encore une infrastructure sous-jacente relativement lointaine. Les cas d’utilisation potentiels incluent l’anti-MEV, les transactions privées, des réseaux plus sécurisés et la prévention de l’espionnage par des tiers. Cependant, il ne s’agit pas de besoins primaires, et l’utilisation de FHE ralentit effectivement le réseau. Franchement, le moment clé de la FHE n’est pas encore arrivé.
En fin de compte, la protection de la vie privée n’est pas une demande forte. Peu de gens sont prêts à payer plus cher pour la protection de la vie privée en tant que service public. Nous devons trouver des scénarios dans lesquels les fonctionnalités calculables des données chiffrées de FHE peuvent réduire les coûts ou améliorer l’efficacité des transactions, générant ainsi une dynamique de marché. Par exemple, il existe de nombreuses solutions anti-MEV, et les nœuds centralisés peuvent résoudre le problème. FHE n’aborde pas directement les points douloureux.
Un autre problème est l’efficacité informatique. À première vue, il s’agit d’un problème technique nécessitant une accélération matérielle ou une optimisation des algorithmes, mais fondamentalement, il s’agit d’un manque de demande du marché, sans incitation pour les parties prenantes du projet à se faire concurrence. L’efficacité informatique résulte de la concurrence. Par exemple, dans le cadre de la demande croissante du marché, les routes SNARK et STARK sont en concurrence, avec divers ZK Rollups qui se livrent une concurrence féroce, des langages de programmation à la compatibilité. Le développement de ZK a été rapide sous la pression de l’argent chaud.
Les scénarios d’application et la mise en œuvre sont les points de rupture pour que FHE devienne une infrastructure blockchain. Sans prendre cette mesure, FHE ne prendra jamais de l’ampleur dans l’industrie de la cryptographie, et les grands projets ne peuvent que bricoler dans leurs petits domaines.
D’après les pratiques de Zama et de ses partenaires, un consensus est de créer de nouvelles chaînes en dehors d’Ethereum et de réutiliser ERC-20 et d’autres composants et normes techniques pour former des chaînes FHE L1/L2 liées à Ethereum. Cette approche permet de tester et de construire rapidement les composants de base de FHE. L’inconvénient est que si Ethereum ne prend pas en support les algorithmes FHE, les solutions de chaîne externes seront toujours gênantes.
Zama reconnaît également ce problème. Outre les bibliothèques liées à la FHE susmentionnées, il a initié l’organisation FHE.org et parrainé des conférences connexes pour traduire davantage de réalisations académiques en applications d’ingénierie.
L’orientation de développement d’Inco Network est une « couche informatique universelle de confidentialité », essentiellement un modèle de fournisseur de services d’externalisation informatique. Il a construit un réseau FHE EVM L1 basé sur Zama. Une exploration intéressante est la coopération avec le protocole de messagerie cross-chain Hyperlane, qui peut déployer des mécanismes de jeu à partir d’une autre chaîne compatible EVM sur Inco. Lorsque le jeu nécessite un calcul FHE, Hyperlane appelle la puissance de calcul d’Inco et renvoie ensuite uniquement les résultats à la chaîne d’origine.
Pour réaliser de tels scénarios envisagés par Inco, les chaînes compatibles EVM doivent faire confiance à la crédibilité d’Inco, et la puissance de calcul d’Inco doit être suffisamment forte pour gérer les exigences de concurrence élevée et de faible latence des jeux blockchain, ce qui est très difficile.
En plus de cela, certaines zkVM peuvent également servir de fournisseurs d’externalisation informatique FHE. Par exemple, RISC Zero a cette capacité. La prochaine étape de la collision entre les produits ZK et FHE pourrait susciter d’autres idées.
En outre, certains projets visent à se rapprocher d’Ethereum ou à en faire partie. Inco peut utiliser la solution de Zama pour L1 et Fhenix peut utiliser la solution de Zama pour EVM L2. Actuellement, ils sont encore en développement, avec de nombreuses directions potentielles. On ne sait pas sur quel produit ils finiront par atterrir. Il peut s’agir d’une L2 axée sur les capacités FEH.
De plus, il y a le concours FHERMA mentionné plus haut. Les développeurs avertis d’Ethereum dans le public peuvent l’essayer, aidant FHE à atterrir tout en gagnant des bonus.
Il y a aussi des projets intrigants comme Sunscreen et Mind Network. Sunscreen, principalement exploité par Ravital, vise à développer un compilateur FHE approprié utilisant l’algorithme BFV mais reste en phase de test et d’expérimentation, loin d’une application pratique.
Enfin, Mind Network se concentre sur la combinaison de FHE avec des scénarios existants tels que le re-staking, mais il reste à voir comment cela sera réalisé.
En conclusion, Elusiv a maintenant été renommé Arcium et a reçu un nouveau funding, se transformant en une solution « FHE parallèle » pour améliorer l’efficacité d’exécution de FHE.
Cet article semble discuter de la théorie et de la pratique de la FHE, mais le thème sous-jacent est de clarifier l’histoire du développement de la technologie cryptographique. Ce n’est pas tout à fait la même chose que la technologie utilisée dans les crypto-monnaies. ZKP et FHE présentent de nombreuses similitudes, l’une d’entre elles étant leur effort pour maintenir la transparence de la blockchain tout en préservant la vie privée. ZKP vise à réduire les coûts économiques dans les interactions L2 <> L1, tandis que FHE est toujours à la recherche de son meilleur scénario d’application.
Classification de la solution :
Le chemin à parcourir est long et difficile. FHE poursuit son exploration. Sur la base de sa relation avec Ethereum, il peut être divisé en trois types :
Contrairement à ZK, qui n’a connu que le lancement pratique de chaînes et l’accélération matérielle dans les étapes ultérieures, FHE repose sur les épaules des géants de ZK. Créer une chaîne FHE est maintenant la tâche la plus simple, mais l’intégrer à Ethereum reste le plus difficile.
Réfléchissez quotidiennement à la future position de la FHE dans le monde de la blockchain :