Nuevo artículo de Vitalik: El futuro y los desafíos de ZK-EVM

Título original: “¿Cómo podría ser un “ZK-EVM consagrado”?”

Autor original: Vitalik

Compilación original: Luccy, BlockBeats

*Nota del editor: El 13 de diciembre, Vitalik Buterin, cofundador de ETH Place, publicó un artículo que profundizaba en la posible implementación de la “ZK-EVM” (Zero-Knowledge Ethereum Virtual Machine) y discutía el diseño de diferentes versiones de la ZK-EVM. *

*El concepto ZK-EVM de Vitalik tiene como objetivo reducir la duplicación de las características del protocolo Ethereum por parte de los proyectos de capa 2 y mejorar su eficiencia en la validación de bloques de Ethereum de capa 1. El artículo señala que los protocolos actuales de EVM de capa 2 (como Optimistic Rollups y ZK Rollups) se basan en mecanismos de verificación de EVM, pero esto también significa que deben confiar en una gran base de código. Una vez que hay una vulnerabilidad en el código base, estas máquinas virtuales pueden correr el riesgo de ser atacadas. *

• Además, mencionó el soporte para “casi-EVM”, que permite que las máquinas virtuales L2 usen ZK-EVM dentro del protocolo con solo pequeñas diferencias con respecto a la EVM, al tiempo que proporciona flexibilidad para cierta personalización de la EVM. *

Los protocolos EVM de capa 2 en ETH, incluidos los op rollups y los ZK rollups, se basan en la validación de EVM. Sin embargo, esto requiere que confíen en una gran base de código, y si ese stock de código está en la laguna, estas máquinas virtuales corren el riesgo de ser pirateadas. Además, incluso las ZK-EVM, que quieren ser totalmente equivalentes a la EVM L1, necesitan alguna forma de gobernanza para replicar los cambios de la EVM L1 en sus propias implementaciones de EVM.

Esta situación no es ideal, ya que estos proyectos están replicando la funcionalidad que ya existe en el protocolo ETH Fang, y ETH gobierno de Fang ya es responsable de actualizar y corregir errores: ¡ZK-EVM básicamente hace el mismo trabajo que validar bloques de ETH L1! Además, en los próximos años, esperamos que los clientes ligeros sean cada vez más potentes y que pronto validen completamente la ejecución de L1 ETH Fang utilizando ZK-SNARKs. En este punto, la red ETH tendrá efectivamente un ZK-EVM incorporado. Así que surge la pregunta: ¿por qué no poner esta localización de ZK-EVM a disposición del proyecto de acumulación?

Este artículo describirá varias versiones posibles de la “ZK-EVM consagrada” y explorará las compensaciones y los desafíos de diseño, así como las razones para no elegir una dirección en particular. Las ventajas de implementar las características del protocolo deben sopesarse con los beneficios que le quedan al ecosistema y los beneficios de mantener el protocolo subyacente simple.

¿Cuáles son los atributos clave que podemos esperar del ZK-EVM que se consagra como estándar?

Función básica: Validar bloques ETH. La función de protocolo (que aún no está claro si se trata de código de operación, precompilación o algún otro mecanismo) debería al menos aceptar la raíz previa al estado, el bloque y la raíz posterior al estado como entrada, y verificar que la raíz posterior al estado es realmente el resultado de ejecutar un bloque sobre la raíz anterior al estado.

Compatibilidad con ETH concepto multicliente. Esto significa que queremos evitar la búsqueda de un único sistema de atestación y, en su lugar, permitir que diferentes clientes usen diferentes sistemas de atestación. Esto, a su vez, significa algunos puntos:

· Requisitos de disponibilidad de datos: Para cualquier ejecución de EVM que utilice las pruebas de ZK-EVM consagradas, queremos poder garantizar que los datos subyacentes sean utilizables para que los probadores que utilizan un sistema de atestación diferente puedan volver a certificar la ejecución y los clientes que dependen de ese sistema de atestación puedan validar estas pruebas recién generadas.

· La prueba existe fuera de la estructura de datos de EVM y fragmentos: La función ZK-EVM no utiliza directamente SNARK como entrada dentro de la EVM, ya que diferentes clientes esperan diferentes tipos de SNARK. En su lugar, podría ser similar a la validación de blobs: las transacciones pueden contener instrucciones que deben probarse (antes del estado, cuerpo del bloque, después del estado), a cuyo contenido se puede acceder mediante códigos de operación o precompilaciones, y las reglas de consenso del lado cliente comprobarán la disponibilidad de datos y la existencia de pruebas para cada notificación realizada en el bloque, respectivamente.

Auditabilidad. Si se demuestra alguna ejecución, queremos que los datos subyacentes sean utilizables para que, en caso de que algo salga mal, los usuarios y desarrolladores puedan inspeccionarlos. En la práctica, esto añade otra razón a la importancia de los requisitos de disponibilidad de datos.

Capacidad de actualización. Si encontramos una vulnerabilidad en una solución ZK-EVM en particular, queremos poder solucionarla rápidamente. Esto significa que no hay necesidad de una bifurcación dura para arreglarlo. Esto añade otra razón para demostrar la importancia de existir fuera de la EVM y de las estructuras de datos de bloques.

Redes que soportan casi-EVM. Uno de los atractivos de L2 es la capacidad de innovar la capa de ejecución y escalar la EVM. Si la máquina virtual (VM) de una L2 determinada es solo ligeramente diferente de la EVM, sería bueno que la L2 pudiera seguir utilizando el mismo ZK-EVM nativo en el protocolo que la EVM, confiando solo en su propio código para las mismas partes de la EVM y en su propio código para diferentes partes. Esto se puede lograr mediante el diseño de una función ZK-EVM que permita al autor de la llamada especificar algunos códigos de operación, direcciones o campos de bits que son manejados por una tabla proporcionada externamente, en lugar de por la propia EVM. También podemos hacer que los costos de gas estén abiertos a la personalización hasta cierto punto.

Sistemas multicliente “abiertos” y “cerrados”

El “concepto multicliente” es probablemente el requisito más afirmado en esta lista. Existe la opción de abandonar esta idea y concentrarse en una solución ZK-SNARK, que simplificará el diseño, pero a costa de un mayor “cambio filosófico” en ETH Workshop (ya que esto sería en realidad una desviación de la filosofía multicliente a largo plazo de ETH Workshop) y la introducción de mayores riesgos. En el futuro a largo plazo, por ejemplo, si las técnicas formales de verificación mejoran, puede ser mejor elegir este camino, pero por ahora, los riesgos parecen demasiado grandes.

Otra opción es un sistema multicliente cerrado en el que se conoce un conjunto fijo de sistemas de atestación dentro del protocolo. Por ejemplo, podríamos decidir usar tres ZK-EVM: PSE ZK-EVM, Polygon ZK-EVM y Kakarot. Un bloque debe llevar prueba de dos de estos tres para que se considere válido. Esto es mejor que un sistema de prueba único, pero hace que el sistema sea menos adaptable porque los usuarios tienen que mantener validadores para cada sistema de prueba conocido, es probable que haya un proceso de gobernanza política para incorporar nuevos sistemas de prueba, etc.

Esto me ha llevado a preferir un sistema abierto y multicliente, donde las pruebas se colocan “fuera de los bloques” y los clientes las verifican por separado. Los usuarios individuales pueden validar bloques con el cliente que deseen, siempre y cuando haya al menos un probador que genere la prueba del sistema. El sistema de atestación ganará influencia convenciendo a los usuarios para que los ejecuten, no convenciendo al proceso de gobernanza del protocolo. Sin embargo, este enfoque tiene costos más complejos de los que veremos.

¿Cuáles son las características clave que queremos que tenga la implementación de ZK-EVM?

Además de la funcionalidad correcta básica y las garantías de seguridad, la característica más importante es la velocidad. Si bien es posible diseñar una función ZK-EVM dentro de un protocolo que sea asíncrono y devuelva solo una respuesta para cada reclamo después de un retraso de N intervalos de tiempo, el problema de que todo lo que sucede en cada bloque es autónomo sería más fácil si pudiéramos garantizar de manera confiable que las pruebas se generarían en cuestión de segundos.

Aunque hoy en día se necesitan muchos minutos u horas para generar pruebas de ETH bloques, sabemos que no hay ninguna razón teórica para evitar la paralelización masiva: siempre podemos combinar suficientes GPU para probar las diferentes partes de la ejecución de bloques por separado y luego usar SNARK recursivos para juntar esas pruebas. Además, la aceleración de hardware a través de FPGA y ASIC puede ayudar a optimizar aún más las pruebas. Sin embargo, llegar a este punto es un desafío de ingeniería importante que no debe subestimarse.

¿Cómo podrían ser las características de ZK-EVM dentro del protocolo?

De forma similar a las transacciones de blobs EIP-4844, introducimos un nuevo tipo de transacción que incluye notificaciones ZK-EVM:

Similar a EIP-4844, el objeto pasado en el mempool será una versión modificada de la transacción:

Este último se puede convertir en el primero, pero no al revés. También hemos ampliado el objeto sidecar de bloque (introducido en EIP-4844) para incluir una lista de pruebas realizadas en un bloque.

Tenga en cuenta que, en la práctica, es posible que desee dividir el sidecar en dos sidecars independientes, uno para blobs y otro para pruebas, y configurar una subred independiente para cada tipo de prueba (y una subred adicional para blobs).

Además de la capa de consenso, agregamos una regla de validación que establece que un bloque solo se aceptará si el cliente ve una prueba válida de cada afirmación en el bloque. La prueba debe ser una declaración de atestación ZK-SNARK, es decir, la concatenación de la transacción_and_witness_blobs es la serialización del par (Block,Witness), el bloque de ejecución es válido en pre_state_root usando Witness (i), y (ii) genera el post_state_root correcto. Potencialmente, los clientes pueden optar por esperar a M de N para varios tipos de atestación.

Hay una nota filosófica aquí de que la ejecución del bloque en sí misma se puede tratar como algo que solo necesita comprobarse junto con una de las tripletas (σpre, σpost, Proof) proporcionadas en el objeto ZKEVMClaimTransaction. Como resultado, la implementación de ZK-EVM de un usuario puede reemplazar a su cliente de ejecución, que seguirá siendo utilizado por (i) probadores y constructores de bloques, y (ii) nodos que se preocupan por indexar y almacenar datos para uso local.

Verificación y recertificación

Supongamos que tiene dos clientes ETH, uno de los cuales usa PSE ZK-EVM y el otro usa Polygon ZK-EVM. Supongamos que en este punto, ambas implementaciones han evolucionado hasta el punto en que pueden probar ETH ejecución de bloques en menos de 5 segundos, y para cada sistema de prueba, hay suficientes voluntarios independientes que ejecutan hardware para generar pruebas.

Desafortunadamente, dado que los sistemas de certificación individuales no están formalizados, no se pueden incentivar en el protocolo, sin embargo, anticipamos que el costo de ejecutar un nodo de prueba de prueba será menor en comparación con el costo de investigación y desarrollo, por lo que simplemente podemos financiar nodos de prueba de prueba a través de un organismo común que financie bienes públicos.

Supongamos que alguien publica una ZKEvmClaimNetworkTransaction, a menos que solo publique una prueba de la versión de PSE ZK-EVM. Al ver esto, el nodo Prueba del polígono ZK-EVM calcula y vuelve a publicar el objeto con la prueba del polígono ZK-EVM.

Esto aumenta la latencia máxima total entre el primer nodo honesto que acepta un bloque y el último nodo honesto que acepta el mismo bloque de δ a 2 δ+Tprove (suponiendo que Tprove < 5 segundos aquí).

La buena noticia, sin embargo, es que si tomamos el determinismo de una sola ranura, es casi seguro que podemos “canalizar” esta latencia adicional junto con la latencia de consenso de varias rondas inherente a los SSF. Por ejemplo, en esta propuesta de 4 ranuras, es posible que el paso de “voto principal” solo necesite verificar la validez básica del bloque, pero el paso de “congelar y confirmar” requerirá la existencia de una prueba.

Extensión: Soporta “casi-EVM”

Un objetivo deseable de la función ZK-EVM es admitir “casi-EVM”: EVM con algunas características adicionales. Esto podría incluir una nueva precompilación, nuevos códigos de operación, permitir que los contratos se escriban en EVM o máquinas virtuales completamente diferentes (por ejemplo, en Arbitrum Stylus), o incluso múltiples EVM paralelas con comunicación cruzada sincrónica.

Algunas modificaciones se pueden soportar de una manera sencilla: podemos definir un lenguaje que permita a ZKEVMClaimTransaction pasar la descripción completa de las reglas de EVM modificadas. Esto se puede utilizar para:

· Tabla de costos de gas personalizada (los usuarios no pueden reducir los costos de gas, pero pueden aumentarlos)

· Deshabilitar ciertos códigos de operación

· Establezca el número de bloque (esto significará que habrá diferentes reglas según la bifurcación dura)

· Establezca un indicador que active el conjunto completo de cambios de EVM que se han estandarizado para el uso de L2 en lugar de L1, u otros cambios más simples

Para permitir que los usuarios agreguen nuevas funcionalidades mediante la introducción de nuevos precompilados (o códigos de operación) de una manera más abierta, podemos agregar un contenido que contenga transcripciones de entrada/salida precompiladas a una parte del blob de ZKEVMClaimNetworkTransaction:

La ejecución de EVM se modificará de la siguiente manera. Las entradas de la matriz se inicializarán como vacías. Cada vez que se llama a la dirección en used_precompile_addresses, anexamos el objeto InputsRecord(callee_address, gas, input_calldata) a las entradas y establecemos el RETURNDATA de la llamada en outputs[i]。 Por último, comprobamos que used_precompile_addresses se ha llamado len(outputs) un total de veces y que inputs_commitments coincide con el resultado de la serialización de SSZ de los compromisos de blob generados con las entradas. El propósito de exponer los insumos_commitments es facilitar SNARKs externos para probar la relación entre los insumos y los productos.

Tenga en cuenta la asimetría entre la entrada y la salida, donde la entrada se almacena en un hash y la salida se almacena en los bytes que se deben proporcionar. Esto se debe a que la ejecución debe ser realizada por un cliente que solo vea la entrada y comprenda la EVM. Las ejecuciones de EVM ya han generado entradas para ellas, por lo que solo necesitan verificar si las entradas generadas coinciden con las entradas declaradas, lo que solo requiere verificación de hash. Sin embargo, el resultado debe proporcionarse a ellos en forma completa, por lo que deben ser datos disponibles.

Otra característica útil podría ser permitir “transacciones privilegiadas”, es decir, transacciones que inician llamadas desde cualquier cuenta del remitente. Estas transacciones pueden ejecutarse entre otras dos transacciones, o cuando se llama a precompile en otra transacción (y posiblemente con privilegios). Esto se puede utilizar para permitir que los mecanismos que no son de EVM devuelvan la llamada a la EVM.

Este diseño se puede modificar para admitir códigos de operación nuevos o modificados, además de la precompilación nueva o modificada. Incluso con solo precompilación, este diseño es muy poderoso. Por ejemplo:

· Al establecer used_precompile_addresses, incluir una lista de direcciones de cuenta normales con ciertas marcas establecidas en sus objetos de cuenta en el estado, y crear un SNARK para demostrar que se creó correctamente, puede admitir características de estilo Arbitrum Stylus en las que el código del contrato se puede escribir en EVM o WASM (u otras máquinas virtuales). Las transacciones privilegiadas se pueden utilizar para permitir que las cuentas de WASM se devuelvan a la EVM.

· Al agregar una comprobación externa para asegurarse de que las transcripciones de entrada/salida y las transacciones privilegiadas realizadas por varias EVM coincidan de la manera correcta, puede demostrar un sistema paralelo de varias EVM que se comunican entre sí a través de un canal de sincronización.

· El cuarto tipo de ZK-EVM puede funcionar al tener múltiples implementaciones: una que convierte Solidity u otros lenguajes de alto nivel directamente en máquinas virtuales compatibles con SNARK, y otra que lo compila en código EVM y lo ejecuta en el ZK-EVM consagrado. La segunda implementación (e inevitablemente más lenta) solo se ejecuta si el probador de errores envía una transacción que indica que hay un error, y si pueden proporcionar una transacción que los dos manejan de manera diferente, pueden ser recompensados.

· Se puede lograr una máquina virtual puramente asincrónica haciendo que todas las llamadas devuelvan cero y asignando las llamadas a las transacciones con privilegios que se agregan al final del bloque.

Extensión: Compatibilidad con certificadores con estado

Uno de los desafíos con el diseño anterior es que no tiene ningún estado, lo que lo hace menos eficiente en términos de utilización de datos. Al admitir la compresión con estado, los envíos ERC 20 pueden ahorrar hasta 3 veces más espacio que cuando se usa solo la compresión sin estado, utilizando la compresión de datos ideal.

Además, las EVM con estado no necesitan proporcionar datos de testigos. En ambos casos, el principio es el mismo: es un desperdicio pedir que los datos estén disponibles, porque ya sabemos que los datos son utilizables porque fueron introducidos o producidos por una ejecución previa de la EVM.

Si queremos que la función ZK-EVM tenga estado, tenemos dos opciones:

1. Requerir que σpre esté vacío, o una lista de datos disponibles para un par clave-valor previamente declarado, o algún σpost ejecutado previamente.

2. Agregue el compromiso de blob de un recibo generado por bloques R a la tupla (σpre,σpost, Proof). Se puede hacer referencia a cualquier promesa de blob generada o utilizada anteriormente, incluidas las que representan bloques, testigos, recibos o incluso transacciones de blob EIP-4844 normales, que pueden tener algún límite de tiempo, en ZKEVMClaimTransaction y se puede acceder a ella durante su ejecución (posiblemente a través de una serie de instrucciones: "Inserte el byte N del compromiso i en la posición j del bloque + datos testigos… N+k− 1 」)。

(1) Básicamente diciendo: en lugar de solidificar la verificación de EVM sin estado, vamos a solidificar las cadenas hijas de EVM. (2) Básicamente, la creación de un algoritmo de compresión con estado mínimo integrado que utiliza un blob usado o generado previamente como diccionario. Ambos agregan la carga de almacenar más información al nodo de prueba, que es solo el nodo de prueba, y en el caso (2), es más fácil limitar esta carga a una cierta cantidad de tiempo que en el caso (1).

El debate entre los sistemas cerrados multiprueba y los datos fuera de la cadena

Un sistema cerrado de múltiples probadores evita muchas de las complejidades anteriores al fijar un cierto número de pruebas en una estructura M-de-N. En particular, los sistemas cerrados de múltiples probadores no tienen que preocuparse por garantizar que los datos estén en la cadena. Además, un sistema cerrado de múltiples filtros permitirá que las pruebas ZK-EVM se ejecuten fuera de la cadena, lo que las hará compatibles con las soluciones de plasma EVM.

Sin embargo, los sistemas cerrados de múltiples probadores aumentan la complejidad de la gobernanza y reducen la auditabilidad, que es una compensación entre el alto costo y estos beneficios.

Si establecemos ZK-EVM como una característica del protocolo, ¿cuál será el papel actual del “proyecto L2”?

El protocolo se encargará de las funciones de verificación de EVM que los equipos de L2 implementan actualmente, pero el proyecto de L2 seguirá siendo responsable de una serie de características importantes:

Preconfirmación rápida: La finalidad de una sola ranura puede ralentizar las ranuras L1, y los proyectos L2 ya están proporcionando a sus usuarios una “preconfirmación” respaldada por la propia seguridad de L2, con una latencia mucho menor que una ranura. Este servicio seguirá siendo un pasivo puro de L2.

Estrategias de mitigación de MEV: Esto puede incluir mempools cifrados, selección secuencial basada en la reputación y otras características que las L1 son reacias a implementar.

Extensiones a la EVM: Los proyectos L2 pueden incorporar extensiones sustanciales a la EVM para proporcionar un valor significativo a sus usuarios. Esto incluye tanto “casi-EVM” como enfoques fundamentalmente diferentes, como el soporte WASM de Arbitrum Stylus y el lenguaje amigable de El Cairo de SNARK.

Comodidad para usuarios y desarrolladores: Los equipos de L2 trabajan mucho para atraer usuarios y proyectos a su ecosistema y hacerlos sentir bienvenidos, y se les compensa adquiriendo MEV y tarifas de congestión dentro de su red. Esta relación llegó para quedarse.

Enlace al artículo original