ZK spécialisé ou ZK généraliste, lequel incarnera l'avenir ?
TechFlow SélectionTechFlow Sélection
ZK spécialisé ou ZK généraliste, lequel incarnera l'avenir ?
Les infrastructures ZK spécialisées deviennent de plus en plus généralistes, tandis que les ZKVM généralistes deviennent de plus en plus spécialisés.
Dédié à des analyses Web3 approfondiesRédaction : mo
Traduction : Luffy, Foresight News
Quelle est l'avenir du ZK : la spécialisation ou la généralisation ? Permettez-moi d’essayer d’y répondre à l’aide d’un schéma :
Comme illustré ci-dessus, pourrions-nous converger à l’avenir vers un point optimal magique sur ce graphique de compromis ?
Non. L’avenir du calcul vérifiable hors chaîne est une courbe continue qui brouille la frontière entre les solutions ZK spécialisées et généralistes. Permettez-moi d’expliquer l’évolution historique de ces termes, ainsi que leur future convergence.
Il y a deux ans, une infrastructure ZK « spécialisée » faisait référence à des frameworks bas niveau comme circom, Halo2 ou arkworks. Les applications ZK construites avec ces outils étaient essentiellement des circuits ZK écrits manuellement. Elles étaient rapides et peu coûteuses pour des tâches spécifiques, mais généralement difficiles à développer et maintenir. Elles ressemblaient aux circuits intégrés spécialisés (ASIC) utilisés dans l’industrie des semi-conducteurs actuelle — des puces en silicium dédiées, comme les puces NAND ou les contrôleurs.
Cependant, au cours des deux dernières années, les infrastructures ZK spécialisées sont progressivement devenues plus « généralistes ».
Nous disposons désormais de frameworks comme ZKML, les coprocesseurs ZK et ZKSQL, qui fournissent des SDK faciles à utiliser et hautement programmables pour créer différents types d’applications ZK, sans avoir à écrire une seule ligne de code de circuit ZK. Par exemple, un coprocesseur ZK permet aux contrats intelligents d’accéder de manière fiable à l’historique de la blockchain, aux événements et aux transactions, puis d’exécuter des calculs arbitraires sur ces données. ZKML permet aux contrats intelligents d’utiliser de façon fiable les résultats d’inférence d’IA pour traiter divers modèles d’apprentissage automatique.
Ces frameworks évolués améliorent considérablement la programmabilité dans leurs domaines cibles, tout en conservant hautes performances et faible coût grâce à des couches d’abstraction (SDK/API) minces, proches du circuit brut.
Ils sont comparables aux GPU, TPU et FPGA du marché des semi-conducteurs : des experts programmables dédiés à un domaine spécifique.
Les ZKVM ont également fait d’importants progrès ces deux dernières années. Il convient de noter que tous les ZKVM généralistes sont construits sur des frameworks ZK bas niveau et spécialisés. L’idée est que vous pouvez écrire des applications ZK en langage de haut niveau (encore plus convivial que les SDK/API), qui seront ensuite compilées en combinaisons de circuits spécialisés et d’ensembles d’instructions (type RISC-V ou similaire à WASM). Ils sont analogues aux puces processeurs (CPU) dans l’industrie des semi-conducteurs.
Le ZKVM constitue donc une couche d’abstraction au-dessus des frameworks ZK bas niveau, tout comme les coprocesseurs ZK.
Comme le disait un sage, une couche d’abstraction peut résoudre tous les problèmes de l’informatique, mais en crée aussitôt un nouveau. Le compromis, voilà la clé. Fondamentalement, avec un ZKVM, nous faisons un compromis entre performance et universalité.
Il y a deux ans, les performances « brutes » des ZKVM étaient effectivement médiocres. Pourtant, en seulement deux ans, leurs performances ont considérablement progressé.
Pourquoi ?
Parce que ces ZKVM « généralistes » sont devenus de plus en plus « spécialisés ». Un facteur clé de cette amélioration des performances est la mise en œuvre de « précompilations ». Ces précompilations sont des circuits ZK spécialisés capables d’exécuter efficacement des programmes fréquemment utilisés, tels que SHA2 ou différentes vérifications de signature, bien plus rapidement que si ceux-ci étaient décomposés en instructions élémentaires du circuit.
La tendance actuelle est donc parfaitement claire.
Les infrastructures ZK spécialisées deviennent de plus en plus généralistes, tandis que les ZKVM généralistes deviennent de plus en plus spécialisés.
Au cours des dernières années, les optimisations apportées à ces deux approches ont permis d’atteindre des points de compromis bien meilleurs qu’auparavant : progresser sur un aspect sans sacrifier l’autre. C’est pourquoi chaque camp pense sincèrement : « Nous sommes assurément l’avenir ».
Toutefois, la sagesse de l’informatique nous rappelle qu’à un moment donné, nous atteindrons un « mur de Pareto optimal » (ligne verte en pointillés), où il ne sera plus possible d’améliorer une caractéristique sans nuire à l’autre.
Un problème crucial se pose alors : un de ces deux types de technologie finira-t-il par remplacer complètement l’autre en temps voulu ?
En nous appuyant sur l’industrie des semi-conducteurs : le marché des CPU représente 126 milliards de dollars, tandis que celui de l’ensemble des circuits intégrés (incluant tous les IC « spécialisés ») atteint 515 milliards de dollars. Je suis convaincu qu’à l’échelle microscopique, l’histoire se répétera ici : ils ne s’élimineront pas mutuellement.
Cela dit, personne aujourd’hui ne dirait : « Hé, j’utilise un ordinateur entièrement piloté par un CPU universel », ou bien : « Ce robot sophistiqué est actionné uniquement par des circuits intégrés spécialisés ».
Oui, nous devrions aborder cette question sous un angle macro. À l’avenir, il existera une courbe de compromis permettant aux développeurs de choisir librement selon leurs besoins.
À l’avenir, les infrastructures ZK spécialisées et les ZKVM généralistes pourront travailler ensemble. Cette synergie peut prendre plusieurs formes. La méthode la plus simple est déjà réalisable aujourd’hui. Par exemple, vous pouvez utiliser un coprocesseur ZK pour générer certains résultats de calcul à partir de l’historique des transactions blockchain, mais la logique métier de calcul sur ces données pourrait être trop complexe pour être simplement exprimée via un SDK/API.
Vous pouvez alors obtenir des preuves ZK performantes et économiques pour les données et résultats intermédiaires, puis les agréger dans une machine virtuelle généraliste via une récursion de preuve.
Bien que je trouve ce genre de débat passionnant, je sais que nous construisons tous ensemble un futur de calcul asynchrone fondé sur le calcul vérifiable hors chaîne pour la blockchain. À mesure que des cas d’usage massifs émergeront au cours des prochaines années, je suis convaincu que ce débat trouvera naturellement sa conclusion.
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
@no89thkey
