Vitalik: Discuta los diversos tipos de versiones "ZK-EVM integradas" y los desafíos de diseño

Texto: Vitalik Buterin

Compilación: 1912212.eth, Foresight News

Los protocolos EVM de capa 2 además de ETH, incluidos los rollups optimistas y los rollups ZK, se basan en la validación de EVM. Sin embargo, esto requiere que confíen en una base de código enorme, y si hay errores en esa base de código, estas máquinas virtuales corren el riesgo de ser pirateadas. Además, esto significa que incluso las ZK-EVM, que quieren ser totalmente equivalentes a la EVM L1, necesitan alguna forma de gobernanza para replicar los cambios en la EVM L1 en sus propias prácticas de EVM.

Esta situación no es ideal, ya que estos proyectos están replicando funcionalidades que ya existen en el protocolo ETH Workshop, y ETH Governance ya es responsable de actualizar y corregir errores: ¡ZK-EVM es esencialmente el mismo trabajo que validar los bloques de Layer 1 ETH Workshop! Además, en los próximos años, esperamos que los clientes ligeros se vuelvan cada vez más potentes, y pronto alcancen el punto en el que los ZK-SNARK se utilicen para validar completamente la ejecución de EVM de Layer 1. En ese momento, la red ETH construirá efectivamente el ZK-EVM incorporado. Entonces, surge la pregunta: ¿por qué no hacer que el ZK-EVM también sea adecuado para rollups?

En este artículo, veremos algunas de las versiones “ZK-EVM integradas” que se pueden implementar, y discutiremos las compensaciones y los desafíos de diseño, así como las razones para no ir en una dirección en particular. Los beneficios de implementar las características del protocolo deben sopesarse frente a los beneficios de dejar las cosas en manos del ecosistema y mantener el protocolo subyacente simple.

¿Qué características clave queremos de la ZK-EVM integrada?

• Función básica: Validar ETH bloques. La función de protocolo (que aún no está claro si se trata de código de operación, precompilación u otro mecanismo) debe aceptar al menos una raíz de preestado, un bloque y una raíz de postestado como entrada, y verificar que la raíz de postestado es realmente el resultado de la ejecución del bloque.
• Compatible con múltiples clientes de ETH Square. Esto significa que queremos evitar un solo sistema de atestación y, en su lugar, permitir que diferentes clientes usen diferentes sistemas de atestación. Esto nos lleva a los siguientes puntos:
• Requisitos de disponibilidad de datos: Para cualquier ejecución de EVM que utilice el ZK-EVM integrado para las pruebas, queremos garantizar la disponibilidad de los datos subyacentes para que los probadores que utilizan un sistema de atestación diferente puedan volver a certificar la ejecución y permitir que los clientes que confían en ese sistema de atestación validen las pruebas recién generadas.
• Las pruebas existen fuera de las estructuras de datos de EVM y fragmentos: La función ZK-EVM incorporada no toma SNARK como entrada dentro de la EVM, ya que diferentes clientes esperarán diferentes tipos de SNARK. En su lugar, podría ser similar a la validación de blobs: una transacción puede incluir notificaciones (antes del estado, cuerpo del bloque, después del estado) que deben certificarse, cuyo contenido puede tener acceso un código de operación o un precompilador, y las reglas de consenso del lado cliente comprobarán la disponibilidad de los datos y la prueba de existencia de cada notificación por separado.
• Auditabilidad. Si se demuestra alguna ejecución, queremos que los datos subyacentes sean utilizables para que, en caso de problema, los usuarios y desarrolladores puedan examinarlos. De hecho, esto añade otra razón por la que los requisitos de disponibilidad de datos son tan importantes.
• Capacidad de actualización. Si se descubre que una solución ZK-EVM tiene un error, queremos poder solucionarlo rápidamente. Esto significa que no hay necesidad de una bifurcación dura para arreglar. Esto se suma a la razón por la que existen pruebas fuera de las estructuras de datos de EVM y bloques.
• Soporta casi todas las EVMs. Uno de los atractivos de L2 es innovar en la capa de ejecución y escalar la EVM. Si la máquina virtual para una L2 determinada es solo un poco diferente de la EVM, entonces sería bueno si la L2 aún pudiera usar el ZK-EVM dentro del protocolo nativo en las mismas partes que la EVM y confiar solo en su propio código en diferentes partes. Esto se puede lograr mediante el diseño de una función ZK-EVM que permita a la persona que llama especificar campos de bits o listas de códigos de operación o direcciones que son manejadas por tablas proporcionadas externamente en lugar de la propia EVM. También podemos hacer que el costo del gas esté abierto a la edición hasta cierto punto.

Sistemas multicliente “abiertos” y “cerrados”

La “filosofía multicliente” es probablemente el requisito más subjetivo de esta lista. Existe la opción de abandonarlo y centrarse en el esquema ZK-SNARK, que simplificará el diseño, pero a costa de ser un “punto de inflexión filosófico” más grande para ETH Workshop (ya que está abandonando efectivamente la filosofía multicliente de larga data de ETH Workshop) e introducir mayores riesgos. En el futuro, cuando la tecnología de verificación formal mejore, puede ser mejor elegir este camino, pero ahora parece que el riesgo es demasiado grande.

Otra opción es un sistema multicliente cerrado en el que se conoce un conjunto fijo de sistemas de atestación en el protocolo. Por ejemplo, podríamos decidir usar tres ZK-EVM: PSE ZK-EVM, Polygon ZK-EVM y Kakarot. Un bloque requiere una prueba proporcionada por dos de estos tres para ser 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 que existe, e inevitablemente habrá procesos de gobernanza política para incorporar nuevos sistemas de prueba, etc.

Esto me motiva a preferir un sistema multicliente abierto, donde las pruebas se colocan “fuera del bloque” y son verificadas por el cliente individualmente. Los usuarios individuales pueden usar cualquier cliente que deseen para validar bloques, siempre y cuando al menos un probador cree una prueba para ese sistema de atestación. 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 un mayor costo de complejidad, como veremos.

¿Qué propiedades clave queremos obtener de la implementación de ZK-EVM?

Además de la corrección funcional básica y las garantías de seguridad, el atributo más importante es la velocidad. Si bien podemos diseñar la función ZK-EVM dentro del protocolo, que es asíncrona y solo devuelve cada respuesta declarada después de un retraso de N ranuras, el problema se vuelve mucho más fácil si podemos garantizar de manera confiable que se generará una prueba en cuestión de segundos, sin importar lo que suceda en cada bloque es autónomo.

Si bien hoy en día se necesitan muchos minutos u horas para generar pruebas para 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 partes individuales de la ejecución de un bloque por separado y luego juntar las pruebas usando SNARK recursivos. 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 gran desafío de ingeniería que no debe subestimarse.

¿Cómo se vería la función ZK-EVM dentro del protocolo?

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

Es importante tener en cuenta que, en la práctica, es posible que queramos dividir la instalación de prueba en dos cargas de prueba independientes, una para blobs y otra para pruebas, y configurar una subred independiente para cada tipo de prueba (y una subred adicional para blobs).

En la capa de consenso, agregamos una regla de validación que solo acepta un bloque si el cliente ve una prueba válida de cada afirmación en el bloque. La prueba debe ser un ZK-SNARK, demostrar que la concatenación de la transacción_and_witness_blobs es la serialización del par (Bloque, Testigo), y que el bloque se ejecuta con pre_state_root en el Testigo

(i) es válida, y

(ii) Genere la publicación correcta_state_root. Posiblemente, el cliente puede optar por esperar varios tipos de prueba de M-de-N.

Es importante tener en cuenta aquí que la ejecución del bloque en sí misma se puede considerar simplemente como una de las tripletas que deben comprobarse junto con las tripletas proporcionadas en el objeto ZKEVMClaimTransaction (σpre, σpost, Proof). Como resultado, la implementación de ZK-EVM del usuario puede reemplazar a su cliente de ejecución; el cliente de ejecución seguirá ejecutándose

(i) Probadores y Constructores de Bloques y:

y (ii) nodos que se preocupan por la indexación y el almacenamiento de datos para uso local.

Además, debido a que esta arquitectura separa la ejecución de la validación, puede proporcionar más flexibilidad y eficiencia para diferentes roles en el ecosistema ETH. Por ejemplo, un probador puede centrarse en generar pruebas sin preocuparse por los detalles de la ejecución, mientras que los clientes de ejecución pueden optimizarse para satisfacer las necesidades de usuarios específicos, como la sincronización rápida o las capacidades avanzadas de indexación.

Verificación y recertificación

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

Desafortunadamente, debido a que los sistemas individuales de prueba de caja no están formalizados, no se pueden incentivar en el protocolo, sin embargo, anticipamos que el costo de ejecutar pruebas será menor en comparación con la investigación y el desarrollo, por lo que podemos financiar fácilmente a los probadores a través de instituciones financiadas para bienes públicos.

Supongamos que alguien publica una ZKEvmClaimNetworkTransaction, pero solo publica una prueba de la versión de PSE ZK-EVM. El nodo de prueba del polígono ZK-EVM ve esto, calcula y vuelve a publicar el objeto, junto con la prueba del polígono ZK-EVM.

Esto aumentará el retraso máximo total entre el primer nodo honesto que acepta un bloque y el último nodo honesto que acepta el mismo bloque de δ a 2δ + Tprove (asumiendo Tprove<5s aquí).

La buena noticia, sin embargo, es que si adoptamos la finalidad de una sola ranura, es casi seguro que podemos “canalizar” este retraso adicional junto con la latencia de consenso de varias rondas inherente a SSF. Por ejemplo, en esta propuesta de 4 ranuras, el paso de “voto principal” podría necesitar solo verificar la validez del bloque base, pero el paso de “congelar y confirmar” requeriría la presencia de una prueba.

Extensión: Soporte para “casi-EVMs”

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

Algunas modificaciones se pueden soportar de una manera sencilla: podemos definir un lenguaje que permita a ZKEVMClaimTransaction pasar la descripción completa de la regla EVM modificada. Esto se puede utilizar en las siguientes situaciones:

1. Tabla de costos de gas personalizada (los usuarios no pueden reducir los costos de gas, pero pueden aumentarlos)
2. Deshabilite ciertos códigos de operación
3. Establezca el número de bloque (esto significará que hay diferentes reglas según la bifurcación dura)
4. Establezca el indicador para activar el conjunto completo de cambios de EVM que ya están estandarizados para L2 pero no para el uso de L1, u otros cambios más simples

Para permitir que los usuarios agreguen nuevas funcionalidades de una manera más abierta, por ejemplo, mediante la introducción de un nuevo precompilado (o código de operación), podemos agregar una forma de incluir los registros de entrada/salida precompilados en la sección de blobs de ZKEVMClaimNetworkTransaction:

class PrecompileInputOutputTran(Container):used_precompile_addresses: Lista[Address][VersionedHash]inputs_commitments: Lista[Bytes]Salidas: Lista

La ejecución de EVM se modificará de la siguiente manera. Una matriz llamada inputs se inicializará como vacía. Cada vez que se llama a la dirección en used_precompile_addresses, agregamos un objeto InputsRecord(callee_address, Gas, input_calldata) a las entradas y establecemos el RETURNDATA llamado en las salidas[i]。 Por último, comprobamos que used_precompile_addresses se llamó len(outputs) un total de veces y que inputs_commitments coincide con el resultado del compromiso del blob resultante con la serialización de entradas SSZ. El propósito de exponer las entradas_commitments es permitir que el SNARK externo demuestre la relación entre las entradas y las salidas.

Tenga en cuenta la asimetría entre las entradas y las salidas, donde las entradas se almacenan en hashes y las salidas se almacenan en bytes que deben proporcionarse. 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 la entrada generada coincide con la entrada declarada, lo que solo requiere verificación de hash. Sin embargo, el resultado debe proporcionarse en su totalidad, por lo que la disponibilidad de los datos debe estar disponible.

Otra característica útil podría ser permitir que se invoquen “transacciones con privilegios” desde cualquier cuenta de remitente. Estas transacciones se pueden ejecutar entre otras dos transacciones, o dentro de otra transacción (y posiblemente con privilegios), mientras se llama a la precompilación. Esto se puede utilizar para permitir que los mecanismos que no son de EVM devuelvan la llamada a la EVM.

El diseño se puede modificar para admitir códigos de operación nuevos o modificados, además de precompilaciones nuevas o modificadas. Incluso con solo precompilación, el diseño es muy potente. Por ejemplo:

La funcionalidad como Arbitrum Stylus se puede admitir configurando used_precompile_addresses para incluir una lista de direcciones de cuenta regulares con un determinado indicador establecido en su objeto de cuenta en el estado, y generando SNARK que demuestren que están construidos correctamente, donde un contrato puede escribir su código en una EVM o WASM (u otra máquina virtual). Las transacciones privilegiadas se pueden utilizar para permitir que las cuentas de WASM devuelvan la llamada a EVM.

Al agregar una verificación externa para garantizar que los registros de entrada/salida y las transacciones privilegiadas realizadas por múltiples EVM coincidan de la manera correcta, se puede demostrar un sistema paralelo de múltiples EVM que se comunican entre sí a través de un canal de sincronización.

Un ZK-EVM de tipo 4 puede funcionar teniendo múltiples implementaciones: una que convierte Solidity u otro lenguaje de nivel superior directamente en una máquina virtual compatible con SNARK, y otra que lo compila en código EVM y lo ejecuta en el ZK-EVM prescrito. La segunda implementación (e inevitablemente más lenta) solo se puede ejecutar si el probador de errores envía una transacción alegando que tiene un error, y si pueden ofrecer que los dos manejan transacciones diferentes, se puede cobrar la recompensa.

Puede implementar una máquina virtual asincrónica pura devolviendo cero a todas las llamadas y asignando las llamadas a las transacciones con privilegios que se agregan al final del bloque.

Extensión: Soporte para prueba de estado

El desafío con el diseño anterior es que es completamente apátrida, lo que lo hace pobre en términos de eficiencia de datos. Con una compresión de datos ideal, la compresión con estado puede hacer que los envíos ERC20 sean más eficientes en cuanto al espacio hasta 3 veces en comparación con la compresión sin estado sola.

Además de esto, las EVM con estado no están obligadas a proporcionar datos de testigos. En ambos casos, el principio es el mismo: es un desperdicio pedir que los datos estén disponibles cuando ya sabemos que los datos están disponibles 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:

Requiere que σpre sea nulo, o una lista predeclarada de claves y valores para los que hay datos disponibles, o algún σpost ejecutado previamente.

Agregue una confirmación de blob a la tupla (σpre, σpost, proof) para el recibo R generado por el bloque. Cualquier compromiso de blob generado o usado anteriormente al que se pueda hacer referencia en ZKEVMClaimTransaction y al que se pueda acceder durante su ejecución, incluidos los compromisos que representan bloques, testigos, recibos o incluso transacciones de blob EIP-4844 normales (puede haber algunos límites de tiempo, a los que se puede hacer referencia mediante una serie de instrucciones: “Inserte el byte N del compromiso i en la posición j del bloque + datos testigo… N+k-1”)

(1) El significado básico es: en lugar de establecer una verificación EVM sin estado, estableceremos una cadena hija EVM.

y (2) esencialmente crea un algoritmo de compresión con estado integrado mínimo que usa un blob usado o generado previamente como diccionario. Ambos colocan una carga en el nodo de prueba, y solo en el nodo de prueba para almacenar más información;

En el caso (2), es más fácil limitar en el tiempo esta carga, mientras que en el caso (1) es más difícil.

Argumentos a favor de los sistemas cerrados de múltiples probadores y los datos fuera de la cadena

Un sistema cerrado de múltiples probadores, en el que hay un número fijo de pruebas en la estructura M-de-N, evita gran parte de la complejidad descrita anteriormente. En particular, un sistema cerrado multi-attester no necesita preocuparse por garantizar que los datos existan 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 multi-attester aumentan la complejidad de la gobernanza y debilitan la auditabilidad, lo cual es un alto costo que debe sopesarse con estas ventajas.

Si incorporamos ZK-EVM y lo convertimos en una característica del protocolo, ¿cuál es el papel actual del proyecto L2?

Las funciones de validación de EVM que actualmente están implementadas por el propio equipo de L2 serán manejadas por el protocolo, pero el proyecto L2 seguirá siendo responsable de una serie de funciones importantes:

• Preconfirmación rápida: La finalidad de una sola ranura puede ralentizar las ranuras L1, mientras que L2 ya proporciona a los usuarios un servicio respaldado por la preconfirmación con su propia seguridad, con una latencia mucho menor que una ranura. Este servicio seguirá siendo responsabilidad exclusiva de L2.

• Estrategias de mitigación de MEV: Esto puede incluir características como mempools cifrados, selección secuencial basada en la reputación, etc., que L1 es reacio a implementar.
• Extensiones a la EVM: Los proyectos de nivel 2 pueden introducir extensiones significativas a la EVM que proporcionan un valor significativo a sus usuarios. Esto incluye “casi-EVMs” y enfoques completamente diferentes, como el soporte WASM de Arbitrum Stylus y el lenguaje amigable de El Cairo de SNARK. • Conveniencia para usuarios y desarrolladores: Los equipos de nivel 2 se esfuerzan mucho en atraer usuarios y proyectos a su ecosistema y hacerlos sentir bienvenidos; se les paga capturando MEV y tarifas de congestión dentro de su red. Esta relación llegó para quedarse.