L'infrastructure ZK dédiée devient de plus en plus polyvalente et le ZKVM à usage général devient plus spécialisé.

Écrit par :mo

Compilé par : Luffy, Foresight News

Spécialisation ou généralisation, lequel est l'avenir de ZK ? Laissez-moi essayer de répondre à cette question avec une image :

Comme le montre la figure, est-il possible pour nous de converger vers un point magique optimal sur le système de coordonnées de compromis à l’avenir ?

Non, l’avenir de l’informatique vérifiable hors chaîne est une courbe continue qui brouille les frontières entre ZK spécialisé et généraliste. Permettez-moi d'expliquer l'évolution historique de ces termes et comment ils fusionneront dans le futur.

Il y a deux ans, l'infrastructure ZK « propriétaire » signifiait des cadres de circuits de bas niveau comme circom, Halo2 et arkworks. Les applications ZK construites à l'aide de ces frameworks sont essentiellement des circuits ZK manuscrits. Ils sont rapides et peu coûteux pour des tâches spécifiques, mais souvent difficiles à développer et à maintenir. Ils sont similaires aux diverses puces de circuits intégrés spécifiques à une application (plaquettes de silicium physiques) que l'on trouve aujourd'hui dans l'industrie des circuits intégrés (circuits intégrés), telles que les puces NAND et les puces de contrôleur.

Cependant, au cours des deux dernières années, l'infrastructure ZK spécialisée est progressivement devenue plus « polyvalente ».

Nous disposons désormais de frameworks ZKML, coprocesseur ZK et ZKSQL qui fournissent des SDK faciles à utiliser et hautement programmables pour créer différentes classes d'applications ZK sans écrire une seule ligne de code de circuit ZK. Par exemple, le coprocesseur ZK permet aux contrats intelligents d'accéder à l'état, aux événements et aux transactions historiques de la blockchain de manière sans confiance et d'exécuter des calculs arbitraires sur ces données. ZKML permet aux contrats intelligents d'exploiter les résultats d'inférence de l'IA pour traiter un large éventail de modèles d'apprentissage automatique de manière sans confiance.

Ces cadres évolués augmentent considérablement la programmabilité dans leurs domaines cibles, tout en conservant des performances élevées et un faible coût grâce à la fine couche d'abstraction (SDK/API) et à des circuits proches du métal nu.

Ils sont similaires aux GPU, TPU et FPGA sur le marché des circuits intégrés : ce sont des experts du domaine programmable.

ZKVM a également parcouru un long chemin au cours des deux dernières années. Il convient de noter que tous les ZKVM à usage général sont construits sur le framework ZK spécialisé de bas niveau. L'idée est que vous pouvez écrire des applications ZK dans un langage de haut niveau (encore plus convivial que le SDK/API) qui se compile en une combinaison de circuits spécialisés et de jeux d'instructions (RISC-V ou quelque chose comme WASM). Ils sont comme les puces CPU dans l'industrie des circuits intégrés.

ZKVM est une couche d'abstraction au-dessus du framework ZK de bas niveau, comme le coprocesseur ZK, etc.

Comme l’a dit un sage, une couche d’abstraction résout tous les problèmes informatiques, mais elle en crée également un autre. Les compromis, c'est la clé. Fondamentalement, avec ZKVM, nous avons un compromis entre performances et polyvalence.

Il y a deux ans, les performances « bare metal » de ZKVM étaient vraiment mauvaises. Cependant, en seulement deux ans, les performances de ZKVM se sont considérablement améliorées.

Pourquoi?

Parce que ces ZKVM « généraux » sont devenus plus « spécialisés ». L'une des principales raisons de l'amélioration des performances est la « précompilation ». Ces précompilateurs sont des circuits ZK spécialisés capables de calculer des programmes de haut niveau couramment utilisés tels que SHA2 et diverses vérifications de signature beaucoup plus rapidement que le processus normal de décomposition en fragments de circuit d'instructions.

La tendance est donc désormais très évidente.

L'infrastructure ZK dédiée devient de plus en plus polyvalente et le ZKVM à usage général devient plus spécialisé.

Les optimisations des deux solutions ces dernières années ont abouti à de meilleurs compromis qu'auparavant : progresser sur un point sans en sacrifier un autre. C'est pourquoi les deux parties estiment que « nous sommes définitivement l'avenir ».

Cependant, la sagesse de l'informatique nous dit qu'à un moment donné, nous rencontrerons le « mur optimal de Pareto » (ligne pointillée verte), c'est-à-dire que nous ne pouvons pas améliorer une performance sans sacrifier celle de l'autre.

Une question à un million de dollars se pose alors : une technologie remplacera-t-elle complètement l’autre à terme ?

Examinons l'industrie des circuits intégrés pour comprendre : le marché des processeurs représente 126 milliards de dollars, tandis que l'ensemble de l'industrie des circuits intégrés (plus tous les circuits intégrés « spécialisés ») représente 515 milliards de dollars. Je suis convaincu que d’un point de vue microéconomique, l’histoire se répétera ici et ne se remplacera pas.

Cela dit, personne aujourd'hui ne dira : « Hé, j'utilise un ordinateur entièrement alimenté par un processeur à usage général » ou « Hé, c'est un robot sophistiqué alimenté par un circuit intégré spécialisé ».

Oui, nous devrions effectivement examiner cette question d’un point de vue macro. Il y aura une courbe de compromis à l’avenir pour permettre aux développeurs de choisir avec flexibilité en fonction de leurs propres besoins.

À l’avenir, l’infrastructure ZK dédiée et le ZKVM à usage général pourront fonctionner ensemble. Ceci peut être réalisé sous de nombreuses formes. La méthode la plus simple est désormais possible. Par exemple, vous pouvez utiliser le coprocesseur ZK pour générer certains résultats de calcul dans l'historique des transactions blockchain, mais la logique métier de calcul au-dessus de ces données est très complexe et vous ne pouvez pas simplement l'exprimer dans le SDK/API.

Ce que vous pouvez faire, c'est prendre des preuves ZK de données et de résultats de calcul intermédiaires hautes performances et à faible coût, puis les agréger dans une VM à usage général via la récursivité des preuves.

Même si je pense que ces types de débats sont intéressants, je sais que nous construisons tous cet avenir informatique asynchrone pour la blockchain, piloté par un calcul vérifiable hors chaîne. À mesure que des cas d’utilisation pour une adoption massive par les utilisateurs émergeront dans les années à venir, je pense que ce débat finira par avoir lieu.