jakiro
Autor: Justin Thaler Fuente: A16Z Traducción: Shan Oppa, Bittain Vision
Máquinas virtuales de conocimiento cero (ZKVMS)El propósito es «popularizar los snarks» para que incluso las personas sin experiencia en snark puedan demostrar que ejecutan un programa correctamente en una entrada específica (o testigo).Su ventaja central radica en la experiencia del desarrollador, pero actualmente los ZKVM sonSeguridadyactuaciónTodavía hay grandes desafíos.Si ZKVMS quiere cumplir con sus promesas, los diseñadores deben superar estos obstáculos.Este artículo explorará las posibles etapas del desarrollo de ZKVM, y puede ser requerido todo el proceso.AñosSolo entonces se puede hacer, no crea que nadie diga que esto se puede lograr rápidamente.
Desafíos
existirSeguridadPor un lado, los ZKVM son proyectos de software altamente complejos que aún están llenos de vulnerabilidades.
existiractuaciónEn cuanto a, puede ser más lento demostrar que un programa se ejecuta correctamente que de forma nativa.Cientos de miles de veces, haciendo la mayoría de las aplicaciones desplegadas en el mundo realNo es factible por ahora.
Aún así, muchas voces en la industria blockchain aún promueven ZKVMSSe puede implementar inmediatamente, e incluso algunos proyectos ya están pagando altos costos computacionales para generar pruebas de cero conocimiento de actividad en la cadena.Sin embargo, dado que todavía hay muchas vulnerabilidades en ZKVMS, este enfoque es en realidad soloUn disfraz costoso, hacer que el sistema parezca que está protegido por Snark, cuando de hecho depende deControl de permiso, o peorExposición al riesgo de ataque.
La realidad es que todavía estamos a años de construir un ZKVM realmente seguro y eficiente.Este artículo propone una serie deEspecífico y en faseEl objetivo de ayudarnos a rastrear el progreso real en ZKVM, debilitar la exageración y guiar a la comunidad a centrarse en los avances tecnológicos reales.
Etapa de desarrollo de seguridad
fondo
Residencia enGruñidodeZKVMSPor lo general, contiene dos componentes centrales:
1.Prueba de oráculo interactivo polinomial (PIOP): Un marco de prueba interactivo para pruebas de polinomios (o restricciones derivadas de polinomios).
2.Esquema de compromiso polinómico (PCS): Asegúrese de que el Prover no pueda forjar los resultados de la evaluación polinomial sin ser detectado.
pase zkvmCodificar trayectorias de ejecución válidas en sistemas de restricciones, asegúrese de la máquina virtualregistroyMemoriay luego use Snark para probar la satisfacción de estas restricciones.
En un sistema tan complejo, la única forma de garantizar que ZKVM sea vulnerable esVerificación formal.Las siguientes son las diferentes etapas de la seguridad de ZKVM, dondeLa primera fase se centra en la corrección del acuerdo,La segunda y tercera etapa se centran en lograr la corrección.
Fase 1 de seguridad: el protocolo correcto
-
Verificación formal de fiabilidad PIOP;
-
PCS es una prueba vinculante de verificación formal bajo ciertos supuestos de cifrado o modelos ideales;
-
Si se usa Fiat-Shamir, el argumento conciso obtenido al combinar PIOP y PCS es una prueba de seguridad de verificación formal en el modelo de Oracle aleatorio (mejorado con otros supuestos de cifrado según sea necesario);
-
El sistema de restricción aplicado por PIOP es equivalente a la prueba de verificación formal de la semántica de las máquinas virtuales;
-
Todas estas secciones están completamente «pegadas» en una sola prueba de snark segura formalmente probada para ejecutar cualquier programa especificado por VM ByTecode.Si el protocolo tiene la intención de implementar cero conocimiento, este atributo también debe verificarse formalmente para garantizar que no se divulgue información confidencial sobre el testigo.
Si se usa ZKVMrecursión, entonces elPIOP, esquemas de compromiso y sistemas de restriccionesTodos deben ser verificados, de lo contrario, este sub-etapa no puede considerarse completo.
Fase 2 de seguridad: Implementación del verificador correcto
Esta etapa requiere ZKVMVerificadorSe lleva a cabo la implementación real (como óxido, solidez, etc.)Verificación formal, asegúrese de que cumpla con los protocolos que se han verificado en la primera fase.Completar esta fase significa ZKVM’slograryDiseño teóricoEs consistente, no solo unoAcuerdo de seguridad en papel, o una especificación ineficiente escrita en un idioma como Lean.
Por quéCentrarse solo en el validador, no en la pruebaHay dos razones principales: primero,Asegúrese de que el validador sea correcto, puede garantizar la integridad del sistema de prueba ZKVM(es decir: asegúrese de que el validador no esté falsificado para aceptar una prueba falsa).Segundo,La implementación del verificador de ZKVM es más que un orden de magnitud más simple que la implementación de Prover, la corrección del verificador es más fácil de garantizar a corto plazo.
Fase 3 de seguridad: la implementación correcta de Prover
Esta etapa requiere ZKVMPruebaLa implementación real deVerificación formal, asegúrese de que puedaGenerado correctamentePrueba del sistema de prueba que se ha verificado en la primera y segunda etapa.El objetivo de esta etapa esLo completo, es decir, cualquier sistema que use ZKVM no podrá probar una declaración legal.Mantente atascado.Si ZKVM necesita tener atributos de conocimiento cero, se debe proporcionar una verificación formal para garantizar que la prueba no divulgue ninguna información sobre el testigo.
Horario estimado
Fase 1 Progress: Podemos esperar algún progreso el próximo año (por ejemplo,ZklibEso es un esfuerzo).Pero ningún ZKVM puede cumplir completamente los requisitos de la Fase 1 en al menos dos años.
Etapas 2 y 3: Estas fases pueden avanzar simultáneamente con ciertos aspectos de la fase 1.Por ejemplo, algunos equipos han demostrado que la implementación del validador de PLONK coincide con el protocolo en el documento (aunque el protocolo en sí puede no verificarse completamente).Aún así, no espero que ningún ZKVM alcance la Fase 3 en menos de cuatro años, tal vez incluso más.
Notas clave: Código de Seguridad Fiat-Shamir versus Byte Verificado
Un gran problema de complejidad es queTodavía hay preguntas de investigación sin resolver sobre la seguridad de la transformación de Fiat-Shamir..Las tres fases de seguridad tratan a Fiat-Shamir y los oráculos aleatorios como absolutamente seguros, pero en realidad puede haber vulnerabilidades en todo el paradigma.Esto se debe aHay una diferencia entre el modelo idealizado de un oráculo aleatorio y la función hash realmente utilizada.
En el peor de los casos, uno ha alcanzadoFase de seguridad 2El sistema puedeEncontrado completamente inseguro debido a problemas relacionados con Fiat-Shamir.Esto merece nuestra gran atención e investigación continua.Es posible que necesitemosModificar la transformación de Fiat-Shamir para defenderse mejor contra tales vulnerabilidades.
Los sistemas que no usan la recursión son teóricamente más seguros, porque algunos ataques conocidos involucran circuitos similares a los utilizados en pruebas recursivas.Pero este riesgo sigue siendo unProblemas básicos no resueltos.
Otro problema a tener en cuenta es que incluso si ZKVM demuestra que un cierto programa de cómputo (especificado por el Bytecode) esActuar correctamente, pero siEl bytecode en sí tiene defectos, entonces el valor de esta pruebaExtremadamente limitado.Por lo tanto, la practicidad de ZKVM depende en gran medida deCómo generar bytecode formalmente verificado, y este desafíoExtremadamente grande,yMás allá del alcance de este artículo.
Sobre la seguridad cuántica
Las computadoras cuánticas no representarán una amenaza grave durante al menos 5 años (o más), mientras que las vulnerabilidades de software son una cuestión de vida o muerte.Por lo tanto, la prioridad actual debe ser lograr los objetivos de seguridad y rendimiento propuestos en este artículo.Si los snarks no seguros pueden cumplir con estos objetivos más rápido, debemos priorizarlos.Considere cambiar cuando los sarcasos resistentes a la cantidad se ponen al día, o cuando hay señales de que las computadoras cuánticas con amenazas reales están a punto de surgir.
Nivel de seguridad específico
Seguridad clásica de 100 bits¿Se utiliza cualquier Snark para proteger activos valiosos?Estándar mínimo(Pero todavía hay algunos sistemasNo cumplir con este bajo nivel).Aun así, esto es todavíaNo debe ser aceptadoLa práctica de criptografía estándar generalmente requiereSeguridad de 128 bits y arriba.Si el rendimiento de Snark está realmente a la altura de los estándar, no debemos reducir la seguridad para mejorar el rendimiento.
Fase de rendimiento
Situación actual
Actualmente, ZKVMPruebaLa sobrecarga del cálculo es aproximadamente1 millón de veces ejecución nativa.En otras palabras, si la ejecución nativa de un programa requiereX ciclos de CPU,EntoncesGenere una prueba de ejecución correctaAproximadamente necesarioX × 1,000,000 de ciclos de CPU.Esta situación esAsí que esto fue hace un año, y todavía esto es hoy(Aunque hay algunos malentendidos).
Algunas declaraciones populares en la industria hoy en día pueden ser engañosas, como:
1.«El costo de generar pruebas para todo Ethereum Mainnet es inferior a $ 1 millón por año».
2.«Casi implementamos la generación de bloques de Ethereum en tiempo real, requiriendo solo docenas de GPU».
3.«Nuestro último ZKVM es 1000 veces más rápido que las generaciones anteriores».
Sin embargo, estas afirmaciones pueden ser engañosas sin contexto:
•1000 veces más rápido que ZKVM más antiguo, y aún puede ser muy lento, esto es más reveladorQué tan malo fue el pasado, no lo bueno que es ahora.
•El volumen informático de la red principal de Ethereum puede aumentar en 10 veces en el futuro, que hará que el rendimiento actual de ZKVM sea mucho menos probable que se mantenga al día con la demanda.
• La llamada generación de pruebas «casi en tiempo real» todavía está bajo las necesidades de muchas aplicaciones de blockchainDemasiado lento(Por ejemploEl optimismo tiene un tiempo de bloque de 2 segundos, mucho más rápido que los 12 segundos de Ethereum).
•«Las GPU funcionan las 24 horas del día, los 7 días de la semana durante mucho tiempo»No disponibleSuficiente actividad garantizada.
• EstosEl tiempo de generación de pruebas suele ser para tamaños de prueba superiores a 1 MB, y esto es para muchas aplicacionesDemasiado grande.
•«Cuesta menos de $ 1 millón al año»Simplemente porqueEthereum Node completo solo realiza cálculos de aproximadamente $ 25 por año.
Para los escenarios de aplicación fuera de Blockchain, esta sobrecarga informática es obviamente demasiado alta.No importa cuántas optimizaciones de computación o ingeniería paralela sean, no puede compensar una sobrecarga de computación tan grande.
El objetivo básico que debemos establecer es: el sobrevalores de rendimiento no es más de 100,000 veces la ejecución nativa.Pero aun así, este sigue siendo solo el primer paso.Si queremos implementar aplicaciones convencionales verdaderamente a gran escala, es posible que necesitemos reducir la sobrecarga a 10,000 veces o menos de la ejecución nativa.
Medición de rendimiento
El rendimiento de Snark tiene tres componentes principales:
1.La eficiencia inherente del sistema probado subyacente.
2.Optimización para aplicaciones específicas(por ejemplo, precompilado).
3.Aceleración de ingeniería y hardware(por ejemplo, GPU, FPGA o CPU de múltiples núcleos).
Mientras que (2) y (3) son críticos para la implementación real, son adecuados para cualquier sistema de prueba, por lo tanto,Mejoras que no necesariamente reflejan gastos generales básicos.Por ejemplo, agregar aceleración y precompilación de GPU a ZKEVM puede mejorar fácilmente la velocidad en 50 veces más rápido que depender únicamente de las CPU, lo que puede hacer que un sistema inherentemente menos eficiente se vea mejor que otro que no ha sido la misma optimización.
Por lo tanto, este artículo se centra en medirRendimiento básico de Snark sin hardware y precompilación dedicados.Esto es diferente del enfoque de evaluación comparativa actual, que generalmente combina los tres factores en un «valor popular».Es comoJuez Diamonds al pulir el tiempo, en lugar de evaluar su claridad inherente.
Nuestro objetivo esLa sobrecarga inherente de aislar sistemas de prueba universal, reduzca las barreras de entrada para las tecnologías que aún no se han estudiado y ayudan a la comunidad a eliminar las distracciones, centrándose así enProbar el progreso real en el diseño del sistema.
Fase de rendimiento
Aquí están los hitos para las cinco fases de rendimiento que he propuesto.Primero, necesitamos reducir significativamente la sobrecarga de Prover en la CPU antes de poder confiar aún más en el hardware para reducir la sobrecarga.Al mismo tiempo, el uso de la memoria también debe mejorarse.
En todas las etapas,Los desarrolladores no deben ajustar el código para el rendimiento de ZKVM.La experiencia del desarrollador es la ventaja central de ZKVM.Si Devex se sacrifica para cumplir con los puntos de referencia de rendimiento, no solo perderá la importancia de la evaluación comparativa, sino que también violará la intención original de ZKVM.
Estos indicadores se centran principalmente enPrueba del costo.Sin embargo, si se permite el validadorCrecimiento de costos ilimitado(es decir, tamaño de prueba ilimitado o tiempo de verificación), entonces cualquier indicador Prover se puede cumplir fácilmente.Por lo tanto, se deben cumplir los requisitos de las siguientes etapas,El tamaño de prueba máximo y el tiempo de verificación máximo deben definirse al mismo tiempo.
Requisitos de la Fase 1: «Costos racionales de verificación no trivial»
•Tamaño de prueba: Debe ser más pequeño que el tamaño del testigo.
•Tiempo de verificación: La velocidad de prueba de verificación no debe ser más lenta que la ejecución nativa del programa (es decir, no debe ser más lenta que la ejecución directa del cálculo).
Estos sonRequisitos mínimos de simplicidad,CerciorarseEl tamaño de prueba y el tiempo de verificación no son peores que enviar un testigo directamente al validador y hacer que lo revisen directamente.
Etapa 2 y superior
•Tamaño de prueba máxima: 256 kb.
•Tiempo de verificación máximo: 16 milisegundos.
Estos límites se ajustan intencionalmente para acomodar nuevas tecnologías de prueba rápida, incluso si pueden generar mayores costos de verificación.Al mismo tiempo, estos límites superiores excluyen pruebas que son tan caras que pocos proyectos están dispuestos a usar en la cadena de bloques.
Etapa de velocidad 1
La prueba de un solo hilo no debe ser más de 100,000 veces más lento que la ejecución nativa(Aplicable a múltiples aplicaciones, no solo a prueba de bloque Ethereum) y no debe confiar en la precompilación.
Específicamente, supongamos que el procesador RISC-V en una computadora portátil moderna funciona.3 mil millones de ciclos por segundo, luego llegar a la etapa 1 significa que el cuaderno puede30,000 ciclos RISC-V/segundoPrueba de generación de velocidad (hilo único).
El costo del validador debe cumplir con el estándar de «costo de verificación no trivial razonable» previamente definido.
Fase 2 de velocidad
La prueba de un solo hilo no debe ser más de 10,000 veces más lento que la ejecución nativa.
o, Dado que algunos métodos prometedores de Snark (especialmente Snch de dominio binario) están limitados por la CPU y la GPU actuales, esta fase se puede cumplir a través de FPGA (o incluso ASIC):
1. Calcule el número de núcleos RISC-V que el FPGA simula a velocidad nativa.
2. Calcule el número de FPGA requeridos para simular y probar la ejecución de RISC-V (casi en tiempo real).
3. Si (2) cantidadNo más de 10,000 veces (1), entonces la etapa 2 está satisfecha.
•Tamaño de prueba: Máximo 256 kb.
•Tiempo de verificación: Máximo 16 milisegundos en la CPU estándar.
Etapa de velocidad 3
Para alcanzarFase 2 de velocidadBasado en elGastos de prueba de prueba dentro de 1000 ×(Aplicable a múltiples aplicaciones) y debe usarsePrecompilación de la síntesis automática y verificación formal.Esencialmente,Personalice dinámicamente el conjunto de instrucciones de cada programa para acelerar la generación de pruebas, pero debe estar garantizadoFacilidad de uso y verificación formal.(acerca de¿Por qué se precompila una espada de doble filo?y por qué la precompilación «escrita a mano» no es un enfoque sostenible, vea la siguiente sección.)
Etapa de memoria 1
En caso de menos de 2 GB de memorialograrEtapa de velocidad 1, y satisfacerCero requisitos de conocimiento.Esta etapa paraDispositivo móvil o navegadorEs crucial yUna gran cantidad de casos de uso de ZKVM de clientesAbrió la puerta.Por ejemplo, se usa un teléfono inteligentePrivacidad de ubicación, credenciales de identidad, etc..Si la generación de prueba requiere más de 1-2 GB de memoria, la mayoría de los dispositivos móviles no funcionarán.
Dos notas importantes:
1. Incluso para la computación a gran escala (que requiere billones de ciclos de CPU de ejecución nativa), el sistema de prueba debe mantener una tapa de memoria de 2 GB, de lo contrario, la aplicabilidad será limitada.
2. Si la prueba es extremadamente lenta, es fácil mantener una tapa de memoria de 2 GB.Por lo tanto, para que la etapa de memoria 1 tenga sentido, la etapa de velocidad 1 debe alcanzarse dentro del límite de memoria de 2 GB.
Etapa de memoria 2
En menos de 200 MB de memorialograrEtapa de velocidad 1(10 veces más rápido que la etapa de memoria 1).
¿Por qué reducirlo a 200 MB?Considerar unEscenarios que no son de blockchain: Cuando visite un sitio web HTTPS, se descargarán certificados de autenticación y cifrado.Si el sitio web envía pruebas de ZK para estos certificados en su lugar, los sitios web grandes pueden necesitar generar cada segundoMillones de pruebas.Si se requieren 2 GB de memoria por prueba, se cumplirá el requisito de recursos informáticosNivel PB, obviamente, no es factible.Por lo tanto, reduzca aún más el uso de la memoriaAplicaciones que no son de blockchainEs crucial.
Precompilado: ¿Última milla o muletas?
PrecompiladoSe refiere aSistema de restricción de snark optimizado específicamente para funciones específicas (como hashing, firmas de curva elíptica).En Ethereum, la precompilación puede reducir la sobrecarga del hashing de Merkle y la verificación de la firma, pero la excesiva dependencia de la precompilación no puede mejorar realmente la eficiencia central de los sarcasgos.
Problemas de precompilación
1. Todavía demasiado lento: Incluso si precompila con hash y firmas, ZKVM todavía tiene el problema de ineficiencia de los sistemas de prueba de núcleo dentro y fuera de la cadena de bloques.
2. Vulnerabilidades de seguridad: Si la precompilación escrita a mano no se verifica formalmente, hay casi ciertas vulnerabilidades, lo que puede conducir a una falla de seguridad catastrófica.
3. Experiencia de pobre desarrollador: Actualmente, muchos ZKVM necesitan desarrolladoresSistema de restricción de escritura a mano, similar al método de programación en la década de 1960, afectando seriamente la experiencia de desarrollo.
4. Benchmark engañoso: Si los puntos de referencia se basan en la optimización de precompilaciones específicas, puede engañar a las personas para concentrarse en optimizar los sistemas de restricción manual en lugar de mejorar el diseño de Snark.
5. Acceso gratuito de E/S y RAMSi bien la precompilación puede mejorar el rendimiento en las tareas de criptografía pesadas, es posible que no proporcionen una aceleración significativa para cargas de trabajo más diversas, ya que incurren en sobrecarga significativa al pasar la entrada/salida, y no pueden usar RAM.
Incluso en un entorno de blockchain, siempre que vaya más allá de un solo L1 como Ethereum (por ejemplo, desea construir una serie de puentes de cadena cruzada), enfrentará diferentes funciones hash y esquemas de firma.La precompilación continua para resolver este problema no es escalable ni presenta un gran riesgo de seguridad.
Creo que la precompilación sigue siendo crucial a largo plazo, pero solo sucederá una vez que se sinteten automáticamente y se validen oficialmente.De esta manera, podemos mantener las ventajas de la experiencia del desarrollador de ZKVM mientras evitamos los riesgos de seguridad catastróficos.Esta vista se refleja en la fase 3.
Horario esperado
Espero que algunos ZKVM lleguen a finales de este año.Etapa de velocidad 1yEtapa de memoria 1.Creo que podemos lograr esto en los próximos dos años.Fase 2 de velocidad, pero no está claro si este objetivo se puede lograr sin nuevas ideas de investigación.
Espero el resto de las etapas (Etapa de velocidad 3yEtapa de memoria 2) Llevará años lograrlo.
Aunque este artículo enumera las etapas de seguridad y rendimiento de ZKVM, respectivamente, los dos no son completamente independientes.A medida que se continúan descubriendo vulnerabilidades en ZKVM, espero que las soluciones de algunas de estas vulnerabilidades inevitablemente conduzcan a una caída de rendimiento significativa.Por lo tanto, en ZKVM, se lograFase de seguridad 2Anteriormente, los resultados de la prueba de rendimiento deben considerarse datos tentativos.
ZKVM tiene un gran potencial para que el conocimiento cero haya demostrado ser realmente popular, pero todavía está en sus primeras etapas, llenas de desafíos de seguridad y cuellos de botella de rendimiento severos.La publicidad del mercado y la publicidad de marketing dificultan la medición del progreso real.Con hitos claros de seguridad y rendimiento, espero proporcionar una hoja de ruta que despeje la niebla.Eventualmente alcanzaremos nuestro objetivo, pero llevará tiempo, así como esfuerzos continuos en investigación e ingeniería.
