Título original: Anuncio de Zeth: el primer zkEVM Type Zero
Dirección: Tim Cartens, Victor Graf, Rami Khalil, Steven Li, Parker Thompson, Wolfgang Welz, Zeth Collaboration
Compilación: bayemon.eth, ChainCatcher
El 25 de agosto, se lanzó públicamente Zeth, el validador de bloques ZK de código abierto de Ethereum basado en RISC Zero zkVM. Zeth hace todo el trabajo necesario para construir nuevos bloques en zkVM sin depender de validadores ni comités de sincronización. Zeth ha sido verificado en múltiples bloques reales de la red principal de Ethereum y ha pasado todas las pruebas relevantes del conjunto de pruebas oficial de Ethereum. Zeth pudo implementar soporte Rust basado en zkVM y placas sólidas que incluyen revm, ethers y Alloy en 4 semanas. Con el soporte de zkVM para la continuidad y los servicios de prueba Bonsai, Zeth puede generar estas pruebas en minutos. Con el soporte de Zeth para la verificación en cadena, cualquiera puede verificar estas pruebas en cadena a bajo costo. En esta publicación, entraremos en más detalles, pero si desea profundizar en el código, consulte el código fuente y visite el portal para desarrolladores de RISC Zero.
Resumen
Hace aproximadamente un año, Vitalik explicó los diferentes tipos de zkEVM:
Ethereum no se diseñó originalmente para ser compatible con ZK, por lo que hay muchas partes del protocolo Ethereum que requieren un uso computacional intensivo para la verificación de ZK. Un EVM Tipo 1 tiene como objetivo replicar completamente Ethereum, por lo que no puede aliviar estas ineficiencias. Actualmente, las pruebas de los bloques de Ethereum tardan horas en completarse.
Si bien ha habido casos en la historia de Ethereum en los que esto ha sido posible, hoy nos complace anunciar que las pruebas de bloques de Ethereum utilizando los servicios zkVM y Bonsai de RISC Zero toman minutos, no horas.
Zeth: Generación de bloques Ethereum verificables
Hoy lanzamos Zeth, un validador de bloques ZK de código abierto para Ethereum en RISC Zero zkVM.
Zeth puede demostrar que un bloque Ethereum determinado es válido sin depender de validadores o comités de sincronización. Esto se debe a que Zeth hace todo el trabajo necesario para generar nuevos bloques en zkVM, incluido:
Verificar firma de transacción
Validar el estado de la cuenta y el almacenamiento con respecto a la raíz del estado del bloque principal.
Transacciones de aplicaciones
Pagar tarifas para bloquear autores.
actualizar estado raíz
Otro trabajo necesario para generar bloques.
Después de generar un nuevo bloque, Zeth calcula y genera su hash. Al ejecutar este proceso en zkVM, podemos obtener pruebas ZK de que los nuevos bloques son válidos.
Aprovechando el zkVM de RISC Zero y las populares cajas Rust como revm, ether y Alloy, escribimos la primera versión de Zeth en menos de 4 semanas. Con el soporte de continuidad de zkVM y el servicio de pruebas Bonsai, la generación de pruebas se puede realizar en cuestión de minutos. Con soporte para la verificación en cadena, podemos verificar estas pruebas en cadena a bajo costo.
Zeth ha sido verificado en múltiples bloques reales de la red principal de Ethereum y ha pasado todas las pruebas relevantes del conjunto de pruebas oficial de Ethereum.
Dado que Zeth construye bloques Ethereum estándar, se puede considerar como un zkEVM tipo 1. Pero es mucho más que eso: debido a que Zeth está construido utilizando tableros de códigos estándar de Rust (los mismos tableros de códigos utilizados por nodos completos populares como Reth), preferimos pensar en él como un zkEVM de clase 0: compatibilidad total con el protocolo y mucha reutilización de código. . **
Este hito representa un gran paso adelante para la tecnología ZK y el ecosistema Ethereum. En esta publicación, analizamos cómo escribir la primera versión de Zeth en unas pocas semanas, su rendimiento, cómo funciona y qué significa esto para el proyecto ZK.
RISC Zero facilita la creación de zk rollups, zkEVM, clientes ligeros y puentes
Escribimos Zeth por dos razones:
Facilite a otros equipos la creación de su propia infraestructura basada en ZK: ZK rollup, zkEVM, ZK light client, ZK bridge, etc. Zeth proporciona todo lo necesario para generar pruebas ZK para bloques basados en EVM. Este es un componente crítico de cualquier zkEVM o puente. Zeth es de código abierto basado en revm, por lo que los desarrolladores de proyectos pueden modificarlo o utilizarlo fácilmente. Las pruebas se pueden verificar en cadena (ideal para puentes y L2) o en una aplicación local (ideal para nodos completos y clientes ligeros).
Realizar investigaciones relacionadas sobre el rendimiento de EVM en zkVM de Zeth, especialmente tareas relacionadas con Ethereum. (Consulte a continuación el análisis de los resultados de la encuesta).
acumulación de zk y zkEVM
Como zkEVM tipo 0, Zeth permite a los desarrolladores crear paquetes acumulativos de zk con un EVM totalmente nativo y compatibilidad con Ethereum. Junto con el soporte de Zeth para la verificación de pruebas en cadena, construir una solución de expansión L2 impulsada por ZK será extremadamente simple.
Los paquetes acumulativos de ZK y los circuitos zkEVM existentes son monolíticos por diseño y no se pueden actualizar sin que un desarrollador tenga un alto nivel de conocimiento de la criptografía ZK. Por el contrario, el enfoque Zeth basado en zkVM permite a cualquier desarrollador personalizarlo y modificarlo según sus necesidades.
Zeth es de código abierto basado en revm, y ajustarlo para que admita otras cadenas compatibles con zkEVM y EVM es una tarea relativamente fácil. Por lo tanto, Zeth tendrá una respuesta relativamente más rápida a futuras actualizaciones de EIP. Además, Zeth también proporciona modularidad, lo que permite a los desarrolladores construir su propia lógica de construcción de bloques en él.
Esperamos que los esfuerzos de Zeth democraticen zk rollup y zkEVM, sabiendo que las soluciones L2 impulsadas por zk anteriormente requerían años de investigación y desarrollo y más de 100 millones de dólares estadounidenses en financiación, que es un consumo que la mayoría de los proyectos no pueden permitirse.
Cliente ligero y puente
No hay duda de que la introducción de la cadena de balizas es una bendición para los puentes y los clientes ligeros. Estas técnicas se basan en el modelo PoS ahora maduro de Ethereum, lo que permite a los clientes ligeros y a los puentes verificar fácilmente los bloques recientes sin reconstruirlos, siempre que todos cumplan con las reglas.
Por supuesto, el objetivo de apostar es proporcionar incentivos económicos para que los nodos sigan las reglas. Sin embargo, la amenaza que Slashing impone a los nodos no puede evitar por completo el mal (los incentivos externos siempre inclinarán la "equilibrio" de intereses hacia el mal) y es muy importante diseñar un cliente ligero o un puente que pueda manejar adecuadamente estos comportamientos maliciosos. duro.
Con herramientas como Zeth, el riesgo de que los nodos hagan el mal se reduce considerablemente. Los clientes ligeros pueden integrarse con Zeth simplemente agregando algunas llamadas a zkVM; las aplicaciones en cadena, como los puentes, pueden integrarse con Zeth utilizando nuestro contrato de verificación de prueba en cadena.
En un futuro próximo, podemos imaginar puentes y clientes ligeros que utilicen pruebas ZK para determinar si un bloque determinado es válido. Este enfoque reduciría en gran medida el riesgo sin aumentar significativamente el costo de validar bloques.
Esto es especialmente importante para cadenas de aplicaciones, ecosistemas modulares y cadenas nuevas que aún no tienen el mismo nivel de seguridad que proporciona la gran comunidad de nodos completos de Ethereum.
Una buena base simplifica el proceso de desarrollo del proyecto
Basado en RISC Zero zkVM y con la arquitectura del conjunto de instrucciones RISC-V, Zeth puede brindar a los desarrolladores una experiencia de programación familiar. Pero nuestro zkVM es más que un simple núcleo RISC-V. También contamos con circuitos de aceleración para tareas criptográficas comunes como hashing y verificación de firmas.
Este enfoque híbrido (combinación de núcleos de CPU de uso general con circuitos de aceleración) nos brinda lo mejor de ambos mundos:
Admite lenguajes de programación convencionales.
El rendimiento de operaciones criptográficas críticas no se ve comprometido.
Como resultado, pudimos construir rápidamente Zeth utilizando paquetes de código Rust existentes de revm, ether y Alloy. Al reutilizar placas existentes, completamos la primera versión de Zeth en menos de 4 semanas. Este tipo de velocidad no es posible en ecosistemas menos maduros.
En términos de rendimiento, Zeth aprovecha nuestros circuitos aceleradores para la verificación de firmas ECDSA, así como Continuidad, una nueva característica de nuestro marco ZK que facilita el uso de grupos de GPU que trabajan en paralelo (usando nVidia CUDA o Apple Metal) para realizar pruebas de gran tamaño rápidamente. cálculos. Las continuaciones son fáciles de usar: esta funcionalidad se proporciona de forma transparente a todos los programas invitados que se ejecutan en zkVM, es decir, no se requieren modificaciones de código para que funcione correctamente.
Con nuestro zkVM, podemos generar rápidamente pruebas ZK de la validez del bloque Ethereum en minutos, no en horas.
Actuación
Cubriremos el rendimiento del generador de bloques Zeth. Zeth todavía es un producto nuevo, por lo que estos números están sujetos a cambios; sin embargo, queríamos proporcionar algunos números concretos que sirvan como base para trabajos futuros.
Cuando se trata de rendimiento, hay varios factores a considerar:
Recursos computacionales necesarios para generar pruebas.
El "tiempo de pared" necesario para generar la prueba (es decir, cuánto tiempo tiene que esperar el usuario para que la prueba esté disponible).
El costo total de generación de pruebas (USD).
Continuidad
El zkVM de Zeth se puede ajustar para mejorar el rendimiento mediante la ejecución continua. Así que necesitamos hacer una pausa por un momento y discutir cómo funciona la "operación continua".
Nuestro zkVM implementa procesadores RISC-V estándar. Por tanto, la ejecución se mide en ciclos. (En nuestro circuito, la mayoría de las instrucciones RISC-V se ejecutan en 1 ciclo, aunque hay excepciones). Los programas simples normalmente requieren sólo unos pocos cientos de miles de ciclos para ejecutarse, pero los programas más complejos pueden requerir miles de millones de ciclos.
En un sistema ZK típico, estos ciclos de ejecución se agrupan en una prueba; a medida que aumenta el número de ciclos, también aumenta el tiempo y la memoria necesarios para generar la prueba. Pero nuestro zkVM no sigue estos estereotipos y, a principios de este año, fuimos pioneros en una nueva característica de continuidad que mejora los inconvenientes de la generación tradicional de esquemas de prueba.
En términos de continuidad, el proceso de prueba se divide en tres fases:
Realizamos los cálculos requeridos en un simulador sin prueba. A lo largo del camino, contamos el número de veces que se ha ejecutado el bucle hasta el momento. A intervalos configurables, tomamos instantáneas del estado del programa. Esto efectivamente divide la ejecución en varias partes. Cada segmento es pequeño y normalmente representa 1 millón de ciclos o menos.
Estas piezas se asignan a un conjunto de trabajadores de generación de pruebas. Generan pruebas ZK para los segmentos de programa determinados. Es importante destacar que pueden hacerlo en paralelo. Siempre que haya suficientes trabajadores, todos los segmentos del programa se pueden probar en el tiempo necesario para probar un segmento del programa. Debido al pequeño tamaño del segmento de red, el tiempo necesario suele ser corto (decenas de segundos).
Cuando se generan pruebas de segmentos, eventualmente se acumularán. Cada operación de "resumen" toma un par de pruebas segmentadas consecutivas y produce una nueva prueba para la combinación de esos segmentos. Por ejemplo, si el segmento 1 prueba que el programa pasó del estado A al estado B, y el segmento 2 prueba que el programa pasó del estado B al estado C, entonces el resumen prueba que el programa pasó del estado A al estado C. Con suficientes trabajadores, esto se puede hacer en tiempo log(N), donde N es el número de fragmentos.
Veremos estas etapas en acción cuando profundicemos en los números.
** ¿Qué tan difícil es construir un bloque Ethereum? **
Primero, veamos la complejidad de construir un bloque Ethereum. En la siguiente tabla, tomamos algunos bloques de Ethereum del mundo real y los reconstruimos usando Zeth en zkVM.
Por ejemplo, el bloque 17606771 produce 2131 extensiones. Cada segmento representa como máximo 2^20 ciclos de ejecución, por lo que todo el cálculo requiere como máximo 2.234.515.456 ciclos de ejecución.
En general, vemos que un bloque típico de Ethereum tarda entre 2 y 400 millones de ciclos en construirse, pero a veces hasta 9,5 mil millones de ciclos. (Al principio nos sorprendió ver que estas diferencias no se reflejaban en el gas de la transacción. Pero después de pensarlo más, tenía sentido: el sistema de gas se diseñó teniendo en cuenta la ejecución regular, no las pruebas ZK).
Con continuidad, esta escala es fácil de gestionar. Según estas cifras, una red peer-to-peer de 10.000 nodos que ejecutan validadores zkVM es suficiente para lograr el mayor rendimiento de validación paralela para los bloques más grandes, que es una fracción de los 700.000 validadores que Ethereum tiene actualmente.
** ¿Cuánto tiempo lleva generar una prueba? **
Para recopilar algunos datos básicos de rendimiento, lanzamos una instancia de prueba de Bonsai con 64 trabajadores de GPU. Luego le pedimos que certificara el bloqueo de 17735424 (182 transacciones, 3242 segmentos o alrededor de 3400 millones de ciclos) utilizando Zeth.
Para generar pruebas, zkVM primero debe dividir la ejecución en segmentos. En la captura de pantalla siguiente, este proceso fue capturado por la tarea utor, que se ejecutó durante 10 minutos. (La mayor parte de ese tiempo se dedica a cosas de AWS, como escribir en el almacenamiento de red). En la máquina local, la misma tarea tarda menos de 6 minutos en completarse. Esperamos reducir este tiempo significativamente durante el próximo año).
El ejecutor finalmente divide la ejecución en 3242 partes. Eso es mucha fragmentación para solo 64 GPU. Por tanto, cada nodo trabajador debe generar 50 pruebas de segmentos. Como se muestra en la siguiente figura, esto lleva 35 minutos. Si tenemos 50 veces más nodos trabajadores, solo tomará 42 segundos.
Una vez completada la prueba del segmento, comienza el resumen. Como hay 3242 segmentos, necesitamos realizar un proceso acumulativo de log_2(3242) = 12 rondas. En las primeras etapas del resumen, hay más trabajadores que trabajadores; por lo tanto, la primera etapa demora 1 minuto, la segunda etapa demora 35 segundos, la tercera etapa demora 25 segundos, y así sucesivamente. En la séptima etapa, el tiempo se estabilizó en poco más de 5 segundos. Asimismo, si tuviéramos más trabajadores, cada etapa solo tomaría 5 segundos.
Una vez finalizado el resumen, se finalizan los resultados, lo que lleva otro minuto.
Como resultado, pudimos generar pruebas en unos 50 minutos (velocidad efectiva de 1,1 MHz) con un tamaño de clúster insuficiente. Si el clúster tiene el tamaño adecuado, estimamos que la generación de pruebas será más rápida:
En el caso completamente paralelizado, el paso de prueba se puede completar en 42 + 12 * 5 + 60 segundos o 2 minutos y 42 segundos.
Si redondeamos de forma conservadora e incluimos el tiempo del ejecutor, el tiempo está entre 9 y 12 minutos (velocidad efectiva 4,7 MHz - 6,3 MHz).
A medida que continuamos mejorando nuestros ejecutores y nuestro marco de pruebas, somos optimistas de que este tiempo se reducirá significativamente durante el próximo año.
Consumo de recursos para generar pruebas
El clúster de prueba anterior se implementó en AWS. Consta de 64 nodos de prueba g5.xlarge y 1 nodo de ejecución m5zn.xlarge. Según Amazon, cada nodo g5.xlarge tiene
1 GPU con memoria GPU de 24 GiB
4 vCPU con una capacidad de memoria de 16 GiB
Al momento de escribir este artículo, el precio bajo demanda para estas instancias es de $1,006/hora y el de las instancias reservadas es de $0,402/hora. Mientras tanto, la hoja de especificaciones de Amazon muestra que nuestro nodo m5zn.xlarge tiene
4 vCPU, 16 GB de RAM
Al momento de escribir este artículo, el precio bajo demanda para esta instancia es de $0,3303/hora.
Podemos usar estos números para estimar aproximadamente el costo de la prueba para el bloque 17735424 descrito anteriormente.
Recuerde que implementamos 64 nodos de prueba y en esta implementación nos llevó 50 minutos (de un extremo a otro) generar una prueba. Ignorando el tiempo de inactividad de los trabajadores, 64 nodos de prueba más un nodo de ejecución cuestan 50/60 * (64 * 0,402 + 0,3303) = 21,72 dólares por 50 minutos. Esta es una sobreestimación porque supone que estamos pagando a trabajadores desempleados. Si no tomamos en cuenta el costo de dejar inactivos a los trabajadores (por ejemplo, cerrarlos o ponerlos en otros trabajos), el costo es de aproximadamente $19,61.
Este bloque tiene 182 transacciones, o $0,11 por transacción.
El valor total de la transacción es 1,125045057 Eth, o alrededor de $2137,59. Por lo tanto, cada dólar de prueba produce 109,01 dólares en fondos de usuario.
La recompensa pagada por el mismo bloque es 0,117623263003047027 Eth (excluidas las tarifas de transacción). En el momento de escribir este artículo, eso es alrededor de $223,48. Por lo tanto, nuestras pruebas cuestan aproximadamente el 8,7% de la recompensa del bloque.
Las tarifas de transacción suman 0,03277635 Eth, o $62,28, más de 3 veces el costo de nuestra prueba.
¡Vale la pena señalar que estas estimaciones en dólares son independientes del tamaño del grupo! Lo que importa es el número de segmentos. Esto se debe a que 1 máquina que realiza 2 trabajos en secuencia cuesta lo mismo que 2 máquinas que realizan 1 trabajo en paralelo. Por lo tanto, si el tamaño del clúster es mayor, las pruebas se generarán más rápido, pero no más caras.
Hay varias formas de reducir aún más los costos. Además de seguir mejorando el rendimiento de zkVM, quizás añadiendo un acelerador Keccak, también podemos buscar instancias más económicas. Es importante destacar que, dadas las máquinas de baja especificación que estamos usando (y nuestro zkVM es compatible con nVidia Cuda y Apple Metal), este trabajo se puede realizar fácilmente a través de una red p2p de PC y Mac de consumo comunes.
Verificación en cadena
Como se mencionó anteriormente, verificamos las pruebas Zeth en Sepolia utilizando el validador RISC Zero Groth16. Esta es una parte relativamente nueva de la pila de protocolos RISC Zero, lanzada a principios de este mes. Funciona utilizando Bonsai para convertir la prueba STARK nativa de zkVM en una prueba SNARK equivalente y enviando esa prueba a un validador SNARK en cadena.
Si vemos la entrada de la transacción como datos UTF-8, vemos que la prueba corresponde al bloque 17735424.
Usando Bonsai, la conversión de STARK a SNARK tarda unos 40 segundos. Verificar el SNARK en cadena costó 245.129 gasolina (~$5,90 al momento de escribir este artículo).
Por supuesto, una ventaja de zkVM es que puede combinar varias pruebas en una. Con esta funcionalidad, se puede verificar un conjunto completo de pruebas en cadena sin utilizar ningún gas adicional. De esta manera, el costo de la verificación en cadena se puede distribuir entre todo el conjunto de pruebas, lo que reduce el costo para todos.
Qué significa esto para Ethereum
Como se mencionó anteriormente, Ethereum no fue diseñado pensando en la compatibilidad con ZK. Como muestra el caso de zkEVM, hay muchas cosas que se pueden hacer de diferentes maneras, especialmente cuando se trata de códigos de operación, firmas digitales y funciones hash.
Si bien estos cambios mejoraron el rendimiento, aún pudimos lograr un rendimiento sólido sin estos cambios. Cuando Vitalik escribió sobre diferentes tipos de zkEVM el año pasado, tomó horas probar la validez de un bloque de Ethereum; ahora podemos hacerlo en minutos. El rendimiento de ZK está mejorando rápidamente y tenemos motivos para creer que esta tendencia continuará en los próximos años.
Apéndice: Cómo funciona Zeth
Esta sección es para desarrolladores.
En términos generales, Zeth construye bloques de la misma manera que un nodo completo: comenzamos con el bloque principal, la lista de transacciones y el autor del bloque, luego hacemos muchos cálculos (verificar firmas, ejecutar transacciones, actualizar el estado global, etc.). y finalmente devolver el nuevo valor hash del bloque.
Pero a diferencia de los nodos completos, esto lo hacemos en zkVM. Esto significa que obtenemos una prueba ZK de que un bloque con un hash determinado es válido.
Por supuesto, esto no está exento de desafíos. En esta sección, presentamos estos desafíos y cómo los abordamos.
Criptografía
El primer desafío es la criptografía. Construir un bloque Ethereum requiere mucho trabajo, los más importantes son el hash (Keccak-256) y la verificación de firmas (ECDSA y secp256k1).
Nuestro zkVM ha acelerado el soporte para curvas elípticas, por lo que la verificación de la firma ECDSA no es difícil.
Pero cuando se trata de hash, no tenemos tanta suerte. Nuestro zkVM ha acelerado el soporte para Sha2-256, pero no (al momento de escribir este artículo) Keccak-256. Por lo tanto, actualmente solo utilizamos la implementación de Keccak en la caja sha3 Rust. A través de la elaboración de perfiles, sabemos que esto requiere muchos ciclos. No es óptimo, pero nuestro zkVM puede manejarlo y podemos reciclar y agregar aceleradores Keccak más adelante.
Cuentas y almacenamiento: rendimiento y seguridad
En Ethereum, las cuentas y el almacenamiento son rastreados por un Merkle Patricia Trie (MPT) global.
En el momento de escribir este artículo, el árbol contenía el estado de casi 250.000.000 de direcciones únicas de Ethereum, según Etherscan. En general, no es una gran cantidad de datos, pero es suficiente para que tengamos cuidado con la forma en que los almacenamos y usamos. En particular, el desempeño del MPT es crítico.
Pero el rendimiento no es el único factor, también hay que considerar la seguridad.
El generador de bloques de Zeth se ejecuta como cliente en zkVM. Esto significa que no puede acceder directamente a la red p2p de Ethereum ni a otros proveedores de RPC. En cambio, debe depender de datos proporcionados por programas separados que se ejecutan fuera de zkVM.
Al analizar la seguridad de una aplicación ZK, debemos asumir que los programas externos son maliciosos y, por lo tanto, pueden proporcionar datos maliciosos. Para evitarlo, las aplicaciones ZK deben verificar que los datos que se les proporcionan sean válidos.
Para los generadores de bloques Zeth, esto significa verificar el estado de todas las cuentas y el almacenamiento relevantes (es decir, las cuentas y el almacenamiento necesarios para ejecutar una lista determinada de transacciones).
Afortunadamente, EIP-1186 proporciona dicho mecanismo, que define una forma estándar de probar el estado de una cuenta determinada (y su almacenamiento) mediante la inclusión de Merkle.
En principio, los generadores de bloques de Zeth podrían verificar el estado de la cuenta y el almacenamiento verificando un conjunto de pruebas de inclusión EIP-1186. Pero este enfoque no es ideal.
En cambio, es mejor utilizar los datos de la prueba de inclusión EIP-1186 para construir un MPT parcial. Este es un tipo de MPT que solo incluye nodos que son relevantes para una lista de transacciones determinada; las ramas no relacionadas simplemente se representan con los hashes correspondientes. Puedes pensar en los MPT parciales como una especie de "unión" de pruebas de inclusión de Merkle o, si lo prefieres, como pruebas de subconjuntos de Merkle.
El proceso de verificar un MPT parcial es básicamente el mismo que verificar una prueba EIP-1186 normal: el hash raíz se calcula y se compara con el estado raíz del bloque principal. Si los dos son iguales, se puede confiar en la integridad de las cuentas y el almacenamiento que contienen.
Una vez que se verifica el MPT parcial, se puede aplicar la transacción y actualizar el MPT parcial. La nueva raíz del estado se puede obtener calculando el nuevo valor hash de la raíz del MPT parcial.
Antes de ejecutar el generador de bloques Zeth, ejecutamos la lista de transacciones en el sandbox para determinar qué cuentas y almacenamiento son relevantes. (Este proceso también nos permite determinar el bloque predecesor relacionado más antiguo, que es necesario para admitir consultas blockhash()).
Obtenemos prueba de inclusión EIP-1186 para cada cuenta y almacenamiento relevantes. (También obtenemos los bloques predecesores relevantes).
Utilizamos estas pruebas de inclusión para crear un MPT parcial que incluya todos los datos relevantes.
Iniciamos zkVM, dejamos que ejecute el generador de bloques Zeth y proporcionamos algunos MPT y otras entradas (bloque principal, lista de transacciones, etc.).
En zkVM, el generador de bloques Zeth:
Verifique que la raíz MPT parcial coincida con la raíz de estado del bloque principal.
Verifique la cadena hash del bloque anterior hasta el bloque principal.
Transacciones de solicitud.
Actualice algunos MPT.
Utilice el nuevo hash raíz del MPT parcial como raíz de estado del nuevo bloque.
Una vez completado el generador de bloques Zeth, generará el valor hash del nuevo bloque.
Este hash incluye un compromiso con el bloque principal y, por lo tanto, la raíz del estado del bloque principal (utilizado para verificar el MPT parcial original). Esto significa que un validador malicioso no puede proporcionar cuentas y almacenamiento con datos no válidos sin proporcionar un bloque principal no válido.
En otras palabras: si el bloque principal es válido, entonces el nuevo bloque generado por Zeth también es válido.
Entonces, si alguien te proporciona un nuevo bloque y una prueba ZK generada por Zeth, puedes verificar la validez del bloque verificando las siguientes tres cosas:
Asegúrese de que la prueba ZK sea válida y de Zeth. Para aplicaciones fuera de la cadena, las funciones proporcionadas por zkVM Rust crate se pueden utilizar para la inspección. Para aplicaciones en cadena, esto se puede verificar utilizando nuestro validador de prueba en cadena.
Asegúrese de que el ZK demuestre que se confirmó el hash del nuevo bloque.
Asegúrese de que el bloque principal tenga el hash que espera.
Si estos se verifican, entonces el nuevo bloque es válido.
Limitaciones y mejoras futuras
El objetivo de nuestro proyecto es estudiar el rendimiento de la construcción de bloques. Por este motivo, decidimos limitar el alcance a los bloques fusionados.
Además, si bien Zeth puede demostrar que un bloque determinado es válido, actualmente no puede probar el consenso (es decir, que el bloque está incluido en la cadena canónica). Esto puede cambiar en el futuro, tal vez agregando comprobaciones de firmas de validadores o comités de sincronización en zkVM.
Finalmente, Zeth es una nueva pieza de software. Si bien hemos realizado algunas pruebas (incluido el conjunto de pruebas de Ethereum y varios bloques del mundo real), es posible que Zeth aún contenga algunos errores. Al momento de escribir este artículo, debe considerarse software experimental.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Explicación detallada del validador de bloques de Ethereum Zeth: el primer zkEVM Tipo 0
Título original: Anuncio de Zeth: el primer zkEVM Type Zero
Dirección: Tim Cartens, Victor Graf, Rami Khalil, Steven Li, Parker Thompson, Wolfgang Welz, Zeth Collaboration
Compilación: bayemon.eth, ChainCatcher
El 25 de agosto, se lanzó públicamente Zeth, el validador de bloques ZK de código abierto de Ethereum basado en RISC Zero zkVM. Zeth hace todo el trabajo necesario para construir nuevos bloques en zkVM sin depender de validadores ni comités de sincronización. Zeth ha sido verificado en múltiples bloques reales de la red principal de Ethereum y ha pasado todas las pruebas relevantes del conjunto de pruebas oficial de Ethereum. Zeth pudo implementar soporte Rust basado en zkVM y placas sólidas que incluyen revm, ethers y Alloy en 4 semanas. Con el soporte de zkVM para la continuidad y los servicios de prueba Bonsai, Zeth puede generar estas pruebas en minutos. Con el soporte de Zeth para la verificación en cadena, cualquiera puede verificar estas pruebas en cadena a bajo costo. En esta publicación, entraremos en más detalles, pero si desea profundizar en el código, consulte el código fuente y visite el portal para desarrolladores de RISC Zero.
Resumen
Hace aproximadamente un año, Vitalik explicó los diferentes tipos de zkEVM:
Si bien ha habido casos en la historia de Ethereum en los que esto ha sido posible, hoy nos complace anunciar que las pruebas de bloques de Ethereum utilizando los servicios zkVM y Bonsai de RISC Zero toman minutos, no horas.
Zeth: Generación de bloques Ethereum verificables
Hoy lanzamos Zeth, un validador de bloques ZK de código abierto para Ethereum en RISC Zero zkVM.
Zeth puede demostrar que un bloque Ethereum determinado es válido sin depender de validadores o comités de sincronización. Esto se debe a que Zeth hace todo el trabajo necesario para generar nuevos bloques en zkVM, incluido:
Después de generar un nuevo bloque, Zeth calcula y genera su hash. Al ejecutar este proceso en zkVM, podemos obtener pruebas ZK de que los nuevos bloques son válidos.
Aprovechando el zkVM de RISC Zero y las populares cajas Rust como revm, ether y Alloy, escribimos la primera versión de Zeth en menos de 4 semanas. Con el soporte de continuidad de zkVM y el servicio de pruebas Bonsai, la generación de pruebas se puede realizar en cuestión de minutos. Con soporte para la verificación en cadena, podemos verificar estas pruebas en cadena a bajo costo.
Zeth ha sido verificado en múltiples bloques reales de la red principal de Ethereum y ha pasado todas las pruebas relevantes del conjunto de pruebas oficial de Ethereum.
Dado que Zeth construye bloques Ethereum estándar, se puede considerar como un zkEVM tipo 1. Pero es mucho más que eso: debido a que Zeth está construido utilizando tableros de códigos estándar de Rust (los mismos tableros de códigos utilizados por nodos completos populares como Reth), preferimos pensar en él como un zkEVM de clase 0: compatibilidad total con el protocolo y mucha reutilización de código. . **
Este hito representa un gran paso adelante para la tecnología ZK y el ecosistema Ethereum. En esta publicación, analizamos cómo escribir la primera versión de Zeth en unas pocas semanas, su rendimiento, cómo funciona y qué significa esto para el proyecto ZK.
RISC Zero facilita la creación de zk rollups, zkEVM, clientes ligeros y puentes
Escribimos Zeth por dos razones:
acumulación de zk y zkEVM
Como zkEVM tipo 0, Zeth permite a los desarrolladores crear paquetes acumulativos de zk con un EVM totalmente nativo y compatibilidad con Ethereum. Junto con el soporte de Zeth para la verificación de pruebas en cadena, construir una solución de expansión L2 impulsada por ZK será extremadamente simple.
Los paquetes acumulativos de ZK y los circuitos zkEVM existentes son monolíticos por diseño y no se pueden actualizar sin que un desarrollador tenga un alto nivel de conocimiento de la criptografía ZK. Por el contrario, el enfoque Zeth basado en zkVM permite a cualquier desarrollador personalizarlo y modificarlo según sus necesidades.
Zeth es de código abierto basado en revm, y ajustarlo para que admita otras cadenas compatibles con zkEVM y EVM es una tarea relativamente fácil. Por lo tanto, Zeth tendrá una respuesta relativamente más rápida a futuras actualizaciones de EIP. Además, Zeth también proporciona modularidad, lo que permite a los desarrolladores construir su propia lógica de construcción de bloques en él.
Esperamos que los esfuerzos de Zeth democraticen zk rollup y zkEVM, sabiendo que las soluciones L2 impulsadas por zk anteriormente requerían años de investigación y desarrollo y más de 100 millones de dólares estadounidenses en financiación, que es un consumo que la mayoría de los proyectos no pueden permitirse.
Cliente ligero y puente
No hay duda de que la introducción de la cadena de balizas es una bendición para los puentes y los clientes ligeros. Estas técnicas se basan en el modelo PoS ahora maduro de Ethereum, lo que permite a los clientes ligeros y a los puentes verificar fácilmente los bloques recientes sin reconstruirlos, siempre que todos cumplan con las reglas.
Por supuesto, el objetivo de apostar es proporcionar incentivos económicos para que los nodos sigan las reglas. Sin embargo, la amenaza que Slashing impone a los nodos no puede evitar por completo el mal (los incentivos externos siempre inclinarán la "equilibrio" de intereses hacia el mal) y es muy importante diseñar un cliente ligero o un puente que pueda manejar adecuadamente estos comportamientos maliciosos. duro.
Con herramientas como Zeth, el riesgo de que los nodos hagan el mal se reduce considerablemente. Los clientes ligeros pueden integrarse con Zeth simplemente agregando algunas llamadas a zkVM; las aplicaciones en cadena, como los puentes, pueden integrarse con Zeth utilizando nuestro contrato de verificación de prueba en cadena.
En un futuro próximo, podemos imaginar puentes y clientes ligeros que utilicen pruebas ZK para determinar si un bloque determinado es válido. Este enfoque reduciría en gran medida el riesgo sin aumentar significativamente el costo de validar bloques.
Esto es especialmente importante para cadenas de aplicaciones, ecosistemas modulares y cadenas nuevas que aún no tienen el mismo nivel de seguridad que proporciona la gran comunidad de nodos completos de Ethereum.
Una buena base simplifica el proceso de desarrollo del proyecto
Basado en RISC Zero zkVM y con la arquitectura del conjunto de instrucciones RISC-V, Zeth puede brindar a los desarrolladores una experiencia de programación familiar. Pero nuestro zkVM es más que un simple núcleo RISC-V. También contamos con circuitos de aceleración para tareas criptográficas comunes como hashing y verificación de firmas.
Este enfoque híbrido (combinación de núcleos de CPU de uso general con circuitos de aceleración) nos brinda lo mejor de ambos mundos:
Como resultado, pudimos construir rápidamente Zeth utilizando paquetes de código Rust existentes de revm, ether y Alloy. Al reutilizar placas existentes, completamos la primera versión de Zeth en menos de 4 semanas. Este tipo de velocidad no es posible en ecosistemas menos maduros.
En términos de rendimiento, Zeth aprovecha nuestros circuitos aceleradores para la verificación de firmas ECDSA, así como Continuidad, una nueva característica de nuestro marco ZK que facilita el uso de grupos de GPU que trabajan en paralelo (usando nVidia CUDA o Apple Metal) para realizar pruebas de gran tamaño rápidamente. cálculos. Las continuaciones son fáciles de usar: esta funcionalidad se proporciona de forma transparente a todos los programas invitados que se ejecutan en zkVM, es decir, no se requieren modificaciones de código para que funcione correctamente.
Con nuestro zkVM, podemos generar rápidamente pruebas ZK de la validez del bloque Ethereum en minutos, no en horas.
Actuación
Cubriremos el rendimiento del generador de bloques Zeth. Zeth todavía es un producto nuevo, por lo que estos números están sujetos a cambios; sin embargo, queríamos proporcionar algunos números concretos que sirvan como base para trabajos futuros.
Cuando se trata de rendimiento, hay varios factores a considerar:
Continuidad
El zkVM de Zeth se puede ajustar para mejorar el rendimiento mediante la ejecución continua. Así que necesitamos hacer una pausa por un momento y discutir cómo funciona la "operación continua".
Nuestro zkVM implementa procesadores RISC-V estándar. Por tanto, la ejecución se mide en ciclos. (En nuestro circuito, la mayoría de las instrucciones RISC-V se ejecutan en 1 ciclo, aunque hay excepciones). Los programas simples normalmente requieren sólo unos pocos cientos de miles de ciclos para ejecutarse, pero los programas más complejos pueden requerir miles de millones de ciclos.
En un sistema ZK típico, estos ciclos de ejecución se agrupan en una prueba; a medida que aumenta el número de ciclos, también aumenta el tiempo y la memoria necesarios para generar la prueba. Pero nuestro zkVM no sigue estos estereotipos y, a principios de este año, fuimos pioneros en una nueva característica de continuidad que mejora los inconvenientes de la generación tradicional de esquemas de prueba.
En términos de continuidad, el proceso de prueba se divide en tres fases:
Realizamos los cálculos requeridos en un simulador sin prueba. A lo largo del camino, contamos el número de veces que se ha ejecutado el bucle hasta el momento. A intervalos configurables, tomamos instantáneas del estado del programa. Esto efectivamente divide la ejecución en varias partes. Cada segmento es pequeño y normalmente representa 1 millón de ciclos o menos.
Estas piezas se asignan a un conjunto de trabajadores de generación de pruebas. Generan pruebas ZK para los segmentos de programa determinados. Es importante destacar que pueden hacerlo en paralelo. Siempre que haya suficientes trabajadores, todos los segmentos del programa se pueden probar en el tiempo necesario para probar un segmento del programa. Debido al pequeño tamaño del segmento de red, el tiempo necesario suele ser corto (decenas de segundos).
Cuando se generan pruebas de segmentos, eventualmente se acumularán. Cada operación de "resumen" toma un par de pruebas segmentadas consecutivas y produce una nueva prueba para la combinación de esos segmentos. Por ejemplo, si el segmento 1 prueba que el programa pasó del estado A al estado B, y el segmento 2 prueba que el programa pasó del estado B al estado C, entonces el resumen prueba que el programa pasó del estado A al estado C. Con suficientes trabajadores, esto se puede hacer en tiempo log(N), donde N es el número de fragmentos.
Veremos estas etapas en acción cuando profundicemos en los números.
** ¿Qué tan difícil es construir un bloque Ethereum? **
Primero, veamos la complejidad de construir un bloque Ethereum. En la siguiente tabla, tomamos algunos bloques de Ethereum del mundo real y los reconstruimos usando Zeth en zkVM.
Por ejemplo, el bloque 17606771 produce 2131 extensiones. Cada segmento representa como máximo 2^20 ciclos de ejecución, por lo que todo el cálculo requiere como máximo 2.234.515.456 ciclos de ejecución.
En general, vemos que un bloque típico de Ethereum tarda entre 2 y 400 millones de ciclos en construirse, pero a veces hasta 9,5 mil millones de ciclos. (Al principio nos sorprendió ver que estas diferencias no se reflejaban en el gas de la transacción. Pero después de pensarlo más, tenía sentido: el sistema de gas se diseñó teniendo en cuenta la ejecución regular, no las pruebas ZK).
Con continuidad, esta escala es fácil de gestionar. Según estas cifras, una red peer-to-peer de 10.000 nodos que ejecutan validadores zkVM es suficiente para lograr el mayor rendimiento de validación paralela para los bloques más grandes, que es una fracción de los 700.000 validadores que Ethereum tiene actualmente.
** ¿Cuánto tiempo lleva generar una prueba? **
Para recopilar algunos datos básicos de rendimiento, lanzamos una instancia de prueba de Bonsai con 64 trabajadores de GPU. Luego le pedimos que certificara el bloqueo de 17735424 (182 transacciones, 3242 segmentos o alrededor de 3400 millones de ciclos) utilizando Zeth.
Para generar pruebas, zkVM primero debe dividir la ejecución en segmentos. En la captura de pantalla siguiente, este proceso fue capturado por la tarea utor, que se ejecutó durante 10 minutos. (La mayor parte de ese tiempo se dedica a cosas de AWS, como escribir en el almacenamiento de red). En la máquina local, la misma tarea tarda menos de 6 minutos en completarse. Esperamos reducir este tiempo significativamente durante el próximo año).
El ejecutor finalmente divide la ejecución en 3242 partes. Eso es mucha fragmentación para solo 64 GPU. Por tanto, cada nodo trabajador debe generar 50 pruebas de segmentos. Como se muestra en la siguiente figura, esto lleva 35 minutos. Si tenemos 50 veces más nodos trabajadores, solo tomará 42 segundos.
Una vez completada la prueba del segmento, comienza el resumen. Como hay 3242 segmentos, necesitamos realizar un proceso acumulativo de log_2(3242) = 12 rondas. En las primeras etapas del resumen, hay más trabajadores que trabajadores; por lo tanto, la primera etapa demora 1 minuto, la segunda etapa demora 35 segundos, la tercera etapa demora 25 segundos, y así sucesivamente. En la séptima etapa, el tiempo se estabilizó en poco más de 5 segundos. Asimismo, si tuviéramos más trabajadores, cada etapa solo tomaría 5 segundos.
Una vez finalizado el resumen, se finalizan los resultados, lo que lleva otro minuto.
Como resultado, pudimos generar pruebas en unos 50 minutos (velocidad efectiva de 1,1 MHz) con un tamaño de clúster insuficiente. Si el clúster tiene el tamaño adecuado, estimamos que la generación de pruebas será más rápida:
En el caso completamente paralelizado, el paso de prueba se puede completar en 42 + 12 * 5 + 60 segundos o 2 minutos y 42 segundos.
Si redondeamos de forma conservadora e incluimos el tiempo del ejecutor, el tiempo está entre 9 y 12 minutos (velocidad efectiva 4,7 MHz - 6,3 MHz).
A medida que continuamos mejorando nuestros ejecutores y nuestro marco de pruebas, somos optimistas de que este tiempo se reducirá significativamente durante el próximo año.
Consumo de recursos para generar pruebas
El clúster de prueba anterior se implementó en AWS. Consta de 64 nodos de prueba g5.xlarge y 1 nodo de ejecución m5zn.xlarge. Según Amazon, cada nodo g5.xlarge tiene
Al momento de escribir este artículo, el precio bajo demanda para estas instancias es de $1,006/hora y el de las instancias reservadas es de $0,402/hora. Mientras tanto, la hoja de especificaciones de Amazon muestra que nuestro nodo m5zn.xlarge tiene
Al momento de escribir este artículo, el precio bajo demanda para esta instancia es de $0,3303/hora.
Podemos usar estos números para estimar aproximadamente el costo de la prueba para el bloque 17735424 descrito anteriormente.
Recuerde que implementamos 64 nodos de prueba y en esta implementación nos llevó 50 minutos (de un extremo a otro) generar una prueba. Ignorando el tiempo de inactividad de los trabajadores, 64 nodos de prueba más un nodo de ejecución cuestan 50/60 * (64 * 0,402 + 0,3303) = 21,72 dólares por 50 minutos. Esta es una sobreestimación porque supone que estamos pagando a trabajadores desempleados. Si no tomamos en cuenta el costo de dejar inactivos a los trabajadores (por ejemplo, cerrarlos o ponerlos en otros trabajos), el costo es de aproximadamente $19,61.
¡Vale la pena señalar que estas estimaciones en dólares son independientes del tamaño del grupo! Lo que importa es el número de segmentos. Esto se debe a que 1 máquina que realiza 2 trabajos en secuencia cuesta lo mismo que 2 máquinas que realizan 1 trabajo en paralelo. Por lo tanto, si el tamaño del clúster es mayor, las pruebas se generarán más rápido, pero no más caras.
Hay varias formas de reducir aún más los costos. Además de seguir mejorando el rendimiento de zkVM, quizás añadiendo un acelerador Keccak, también podemos buscar instancias más económicas. Es importante destacar que, dadas las máquinas de baja especificación que estamos usando (y nuestro zkVM es compatible con nVidia Cuda y Apple Metal), este trabajo se puede realizar fácilmente a través de una red p2p de PC y Mac de consumo comunes.
Verificación en cadena
Como se mencionó anteriormente, verificamos las pruebas Zeth en Sepolia utilizando el validador RISC Zero Groth16. Esta es una parte relativamente nueva de la pila de protocolos RISC Zero, lanzada a principios de este mes. Funciona utilizando Bonsai para convertir la prueba STARK nativa de zkVM en una prueba SNARK equivalente y enviando esa prueba a un validador SNARK en cadena.
Si vemos la entrada de la transacción como datos UTF-8, vemos que la prueba corresponde al bloque 17735424.
Usando Bonsai, la conversión de STARK a SNARK tarda unos 40 segundos. Verificar el SNARK en cadena costó 245.129 gasolina (~$5,90 al momento de escribir este artículo).
Por supuesto, una ventaja de zkVM es que puede combinar varias pruebas en una. Con esta funcionalidad, se puede verificar un conjunto completo de pruebas en cadena sin utilizar ningún gas adicional. De esta manera, el costo de la verificación en cadena se puede distribuir entre todo el conjunto de pruebas, lo que reduce el costo para todos.
Qué significa esto para Ethereum
Como se mencionó anteriormente, Ethereum no fue diseñado pensando en la compatibilidad con ZK. Como muestra el caso de zkEVM, hay muchas cosas que se pueden hacer de diferentes maneras, especialmente cuando se trata de códigos de operación, firmas digitales y funciones hash.
Si bien estos cambios mejoraron el rendimiento, aún pudimos lograr un rendimiento sólido sin estos cambios. Cuando Vitalik escribió sobre diferentes tipos de zkEVM el año pasado, tomó horas probar la validez de un bloque de Ethereum; ahora podemos hacerlo en minutos. El rendimiento de ZK está mejorando rápidamente y tenemos motivos para creer que esta tendencia continuará en los próximos años.
Apéndice: Cómo funciona Zeth
Esta sección es para desarrolladores.
En términos generales, Zeth construye bloques de la misma manera que un nodo completo: comenzamos con el bloque principal, la lista de transacciones y el autor del bloque, luego hacemos muchos cálculos (verificar firmas, ejecutar transacciones, actualizar el estado global, etc.). y finalmente devolver el nuevo valor hash del bloque.
Pero a diferencia de los nodos completos, esto lo hacemos en zkVM. Esto significa que obtenemos una prueba ZK de que un bloque con un hash determinado es válido.
Por supuesto, esto no está exento de desafíos. En esta sección, presentamos estos desafíos y cómo los abordamos.
Criptografía
El primer desafío es la criptografía. Construir un bloque Ethereum requiere mucho trabajo, los más importantes son el hash (Keccak-256) y la verificación de firmas (ECDSA y secp256k1).
Nuestro zkVM ha acelerado el soporte para curvas elípticas, por lo que la verificación de la firma ECDSA no es difícil.
Pero cuando se trata de hash, no tenemos tanta suerte. Nuestro zkVM ha acelerado el soporte para Sha2-256, pero no (al momento de escribir este artículo) Keccak-256. Por lo tanto, actualmente solo utilizamos la implementación de Keccak en la caja sha3 Rust. A través de la elaboración de perfiles, sabemos que esto requiere muchos ciclos. No es óptimo, pero nuestro zkVM puede manejarlo y podemos reciclar y agregar aceleradores Keccak más adelante.
Cuentas y almacenamiento: rendimiento y seguridad
En Ethereum, las cuentas y el almacenamiento son rastreados por un Merkle Patricia Trie (MPT) global.
En el momento de escribir este artículo, el árbol contenía el estado de casi 250.000.000 de direcciones únicas de Ethereum, según Etherscan. En general, no es una gran cantidad de datos, pero es suficiente para que tengamos cuidado con la forma en que los almacenamos y usamos. En particular, el desempeño del MPT es crítico.
Pero el rendimiento no es el único factor, también hay que considerar la seguridad.
El generador de bloques de Zeth se ejecuta como cliente en zkVM. Esto significa que no puede acceder directamente a la red p2p de Ethereum ni a otros proveedores de RPC. En cambio, debe depender de datos proporcionados por programas separados que se ejecutan fuera de zkVM.
Al analizar la seguridad de una aplicación ZK, debemos asumir que los programas externos son maliciosos y, por lo tanto, pueden proporcionar datos maliciosos. Para evitarlo, las aplicaciones ZK deben verificar que los datos que se les proporcionan sean válidos.
Para los generadores de bloques Zeth, esto significa verificar el estado de todas las cuentas y el almacenamiento relevantes (es decir, las cuentas y el almacenamiento necesarios para ejecutar una lista determinada de transacciones).
Afortunadamente, EIP-1186 proporciona dicho mecanismo, que define una forma estándar de probar el estado de una cuenta determinada (y su almacenamiento) mediante la inclusión de Merkle.
En principio, los generadores de bloques de Zeth podrían verificar el estado de la cuenta y el almacenamiento verificando un conjunto de pruebas de inclusión EIP-1186. Pero este enfoque no es ideal.
En cambio, es mejor utilizar los datos de la prueba de inclusión EIP-1186 para construir un MPT parcial. Este es un tipo de MPT que solo incluye nodos que son relevantes para una lista de transacciones determinada; las ramas no relacionadas simplemente se representan con los hashes correspondientes. Puedes pensar en los MPT parciales como una especie de "unión" de pruebas de inclusión de Merkle o, si lo prefieres, como pruebas de subconjuntos de Merkle.
El proceso de verificar un MPT parcial es básicamente el mismo que verificar una prueba EIP-1186 normal: el hash raíz se calcula y se compara con el estado raíz del bloque principal. Si los dos son iguales, se puede confiar en la integridad de las cuentas y el almacenamiento que contienen.
Una vez que se verifica el MPT parcial, se puede aplicar la transacción y actualizar el MPT parcial. La nueva raíz del estado se puede obtener calculando el nuevo valor hash de la raíz del MPT parcial.
En zkVM, el generador de bloques Zeth:
Una vez completado el generador de bloques Zeth, generará el valor hash del nuevo bloque.
Este hash incluye un compromiso con el bloque principal y, por lo tanto, la raíz del estado del bloque principal (utilizado para verificar el MPT parcial original). Esto significa que un validador malicioso no puede proporcionar cuentas y almacenamiento con datos no válidos sin proporcionar un bloque principal no válido.
En otras palabras: si el bloque principal es válido, entonces el nuevo bloque generado por Zeth también es válido.
Entonces, si alguien te proporciona un nuevo bloque y una prueba ZK generada por Zeth, puedes verificar la validez del bloque verificando las siguientes tres cosas:
Si estos se verifican, entonces el nuevo bloque es válido.
Limitaciones y mejoras futuras
El objetivo de nuestro proyecto es estudiar el rendimiento de la construcción de bloques. Por este motivo, decidimos limitar el alcance a los bloques fusionados.
Además, si bien Zeth puede demostrar que un bloque determinado es válido, actualmente no puede probar el consenso (es decir, que el bloque está incluido en la cadena canónica). Esto puede cambiar en el futuro, tal vez agregando comprobaciones de firmas de validadores o comités de sincronización en zkVM.
Finalmente, Zeth es una nueva pieza de software. Si bien hemos realizado algunas pruebas (incluido el conjunto de pruebas de Ethereum y varios bloques del mundo real), es posible que Zeth aún contenga algunos errores. Al momento de escribir este artículo, debe considerarse software experimental.