1/ Attention au battage médiatique : si les SNARK et les zkVM sont très prometteurs, ils ne sont pas prêts pour des déploiements complexes et à fort enjeu. Les bugs sont partout, la vérification formelle n’en est qu’à ses balbutiements et les preuves peuvent être des centaines de milliers de fois plus lentes que l’exécution native.

2/ Je viens de publier un article décrivant une feuille de route structurée pour le développement de zkVM. Il sépare les « étapes de sécurité » des « étapes de vitesse », ce qui nous donne un moyen transparent de suivre les progrès. Lisez-le ici :

3/ Sur la sécurité, j’identifie trois étapes pour la vérification formelle : • Protocoles vérifiés • Vérificateurs vérifiés • Vérificateurs vérifiés Jusqu’à ce que nous atteignions l’étape 2, nous ne pouvons pas vraiment qualifier une zkVM de « sécurisée » – et il est probable que cela prenne encore plusieurs années.

4/ En termes de performances, les frais généraux par rapport à l’exécution native dépassent toujours 100 000 ×, ce qui est un échec pour la plupart des cas d’utilisation. Mon article propose cinq « étapes de performance » pour réduire cette surcharge de plusieurs ordres de grandeur et éventuellement permettre des preuves sur l’appareil.

5/ Il est crucial d’isoler l’efficacité fondamentale d’un système de preuve. À l’heure actuelle, de nombreux benchmarks regroupent tout (système de preuve, ingénierie, boosts matériels et précompilés réglés à la main) en un seul chiffre d’affaires, obscurcissant ainsi notre véritable position.

6/ Alors oui, les zkVM et SNARK ont un potentiel énorme, mais on flirte avec le désastre si on fait semblant qu’ils sont prêts pour le prime time. J’utiliserai ces étapes pour suivre les progrès de zkVM dans les années à venir, et j’espère que d’autres le feront aussi. Consultez mon article ici :