Vitalik appelle les développeurs ZK et FHE à "montrer directement le taux de cryptage": vous pouvez voir la différence d'un coup d'œil et parler ensuite d'optimisation
La technologie de confidentialité doit être claire en un coup d'œil. Vitalik Buterin a appelé les développeurs à montrer directement le « taux d'efficacité » lorsqu'ils parlent des performances du ZK et du FHE.
(Résumé préliminaire: La Fondation Ethereum a créé un «Groupe de recherche sur la confidentialité» pour promouvoir six feuilles de route majeures et lancer pleinement la concurrence sur le volet de la confidentialité)
(Supplément de référence: La Fondation Ethereum a publié un plan de confidentialité de bout en bout, une approche en trois volets pour renforcer les fondations de DeFi et de la conformité)
Contenu de cet article
Le co-fondateur d'Ethereum, Vitalik Buterin, a récemment publié un article sur la plateforme X, recommandant aux développeurs d'évaluer les preuves à connaissance nulle (ZK) et le chiffrement entièrement homomorphique (FHE), il faudrait abandonner l'indicateur habituel de « N opérations par seconde » et se concentrer plutôt sur le rapport d'efficacité « temps de calcul du chiffrement/temps de calcul d'origine ». L'intention est de proposer une norme de test plus directe pour la faisabilité de la technologie de confidentialité Web3.
Vitalik se concentre sur le ratio d'efficacité
Les mesures de débit traditionnelles sont extrêmement dépendantes de l'environnement matériel et ne peuvent pas révéler la véritable charge causée par la couche de chiffrement. Vitalik souligne que si les développeurs savent que le calcul initial ne prend qu'une milliseconde, ils peuvent directement déduire du taux d'efficacité la durée d'amplification du cryptage.
Traduction du tweet de Vitalik:
J'espère que davantage de personnes utilisant ZK (connaissance nulle) et FHE (cryptage entièrement homomorphe) pourront utiliser des valeurs de ratio pour exprimer la surcharge supplémentaire ("temps de calcul sous protection cryptographique" vs "temps de calcul d'origine"), au lieu de simplement dire "nous pouvons effectuer N opérations par seconde".
Ceci est plus indépendant du matériel et peut fournir un chiffre très informatif: si mon application est protégée par la cryptographie au lieu de s'appuyer sur la confiance, quel degré d'efficacité vais-je sacrifier?
C'est aussi généralement mieux pour l'estimation, car en tant que développeur, jesai déjà combien de temps prend le calcul brut, et je prends simplement ce temps et je le multiplie par le multiplicateur.
(Oui, je sais que c'est difficile, car les opérations requises entre "l'exécution" et la "génération d'une preuve" sont de nature différente, impliquant notamment SIMD/parallélisation et les modèles d'accès à la mémoire, donc même le rapport est toujours affecté par le matériel dans une certaine mesure. Mais même ainsi, je pense toujours qu'exprimer la surcharge sous forme de multiple, même si ce n'est pas parfait, est toujours un bon indicateur.)
J'aimerais que davantage de personnes ZK et FHE donnent leur temps système sous forme de ratio (temps de calcul en cryptographie vs temps de calcul brut), plutôt que de simplement dire "nous pouvons faire N opérations par seconde"
C'est plus indépendant du matériel, et cela donne un chiffre très informatif: quelle est mon efficacité…
— vitalik.eth (@VitalikButerin) 18 octobre 2025
Vitalik a souligné que même si ce rapport sera toujours affecté par la disposition de la mémoire, le degré de parallélisation et les différences entre les jeux d'instructions, il permet au moins à la communauté "d'utiliser la même règle" pour mesurer différentes solutions.
Gloutons d'étranglement en termes de performances de ZK et FHE
ZK et FHE ont des fonctions très différentes en matière de protection de la vie privée des utilisateurs, mais ils sont également confrontés à des frais généraux élevés. À mesure que la complexité du circuit ZK augmente, le temps de génération de la preuve peut prendre des centaines de fois. Le goulot d’étranglement du FHE est encore plus évident. La version FHE de l'inférence d'apprentissage automatique est 20000 fois plus lente que le texte brut.
Ces retards rendent difficile la mise en œuvre de scénarios tels que DeFi, l'identité décentralisée (DID) et l'IA en chaîne, et soulignent également l'importance du cadre de ratio d'efficacité. Vitalik appelle donc chacun à voir le poids de chaque solution avant de pouvoir parler d’optimisation.
Chemin d'optimisation et coopération écologique
L'initiative de Vitalik encourage la communauté à réaffecter les ressources en R&D. On constate qu’à court terme, l’innovation au niveau des algorithmes reste le principal moyen de réduire ce ratio. Le prochain moyen terme est la mise à niveau des équipements informatiques GPU ou ASIC, qui devrait réduire le temps de calcul du temps absolu à un niveau acceptable pour les utilisateurs.
À long terme, le chiffrement sélectif et la collaboration entre couches seront essentiels pour favoriser une adoption massive. Actuellement, l'industrie du cryptage promeut la normalisation des circuits ZK, l'optimisation du compilateur FHE et le partage de preuves hors chaîne. L'objectif est de réduire le ratio d'efficacité sans affaiblir la confidentialité et de gagner davantage de scénarios pour les applications décentralisées.
