1/ Cuidado con el bombo: si bien las SNARK y las zkVM son inmensamente prometedoras, no están preparadas para implementaciones complejas y de alto riesgo. Los errores están en todas partes, la verificación formal es incipiente y las pruebas pueden ser cientos de miles de veces más lentas que la ejecución nativa.

2/ Acabo de publicar un post en el que se describe una hoja de ruta estructurada para el desarrollo de zkVM. Separa las "etapas de seguridad" de las "etapas de velocidad", lo que nos brinda una forma transparente de realizar un seguimiento del progreso. Léelo aquí:

3/ En cuanto a la seguridad, identifico tres etapas para la verificación formal: • Protocolos verificados • Verificadores verificados • Probadores verificados Hasta que lleguemos a la Etapa 2, realmente no podemos llamar a una zkVM "segura", y es probable que aún falten varios años para llegar allí.

4/ En cuanto al rendimiento, los gastos generales frente a la ejecución nativa siguen superando los 100.000×, un obstáculo para la mayoría de los casos de uso. Mi publicación propone cinco "etapas de rendimiento" para reducir esa sobrecarga en órdenes de magnitud y, finalmente, habilitar pruebas en el dispositivo.

5/ Crucialmente, debemos aislar la eficiencia fundamental de un sistema de prueba. En este momento, muchos puntos de referencia agrupan todo (sistema de prueba, ingeniería, mejoras de hardware y precompilaciones ajustadas a mano) en un solo número de primera línea, oscureciendo dónde nos encontramos realmente.

6/ Así que sí, las zkVM y las SNARK tienen un enorme potencial, pero coqueteamos con el desastre si pretendemos que están listas para el horario de máxima audiencia. Usaré estas etapas para realizar un seguimiento del progreso de zkVM en los próximos años, y espero que otros también lo hagan. Echa un vistazo a mi publicación aquí: