V Shen Xinwen: Después de ETH ZK incorporado de Fang, ¿hacia dónde se dirige la capa 2?

Producido | Diario

Compilar | Loopy Lu

Hoy, Vitalik Buterin ha publicado un nuevo artículo en la comunidad ETH titulado “¿Cómo podría ser un ZK-EVM incorporado?”. Este artículo explora cómo ETH Workshop tendrá su propio ZK-EVM integrado en futuras actualizaciones de red.

Como todos sabemos, en el contexto del lento desarrollo de la ETH, casi todas las Capas 2 convencionales ya tienen ZK-EVM, pero cuando la red principal del taller ETH encapsule su propia ZK-EVM, ¿habrá un conflicto entre el posicionamiento de roles de la red principal y la Capa 2?

En este artículo, Vitalik Buterin enfatiza la importancia de la compatibilidad, la disponibilidad de datos y la auditabilidad, y explora las posibilidades de implementar certificados eficientes y con estado. Además, el artículo explora la posibilidad de implementar pruebas de estado para la eficiencia, y discute el papel de los proyectos de Capa 2 en la provisión de preconfirmación rápida y estrategias de mitigación de MEV. Este artículo refleja el equilibrio entre avanzar en el desarrollo de la red ETH a través de ZK-EVM mientras se mantiene su flexibilidad.

Odaily Planet Daily ha compilado el artículo original, y el texto completo del artículo es el siguiente:

Los rollups optimistas y los rollups ZK, como protocolos EVM de capa 2 además de ETH, se basan en la verificación de EVM. Sin embargo, esto requiere que confíen en una base de código grande y, si hay errores en esta base de código, estas máquinas virtuales corren el riesgo de ser pirateadas. Esto también significa que las ZK-EVM, incluso si quieren ser totalmente equivalentes a la EVM L1, necesitarán alguna forma de gobernanza para replicar los cambios de la EVM L1 en sus propias implementaciones de EVM.

Esta no es una situación ideal. Debido a que estos proyectos están replicando la funcionalidad que ya existe en el ETH Workshop Protocol para sí mismos, ETH Governance ya es responsable de actualizar y corregir errores, y lo que ZK-EVM básicamente hace es validar los bloques de ETH de capa 1. En los próximos años, esperamos que los clientes ligeros sean cada vez más potentes y pronto podrán utilizar ZK-SNARK para validar completamente las ejecuciones de L1 EVM. En ese momento, la red ETH tendrá un ZK-EVM en un paquete. Entonces, surge la pregunta: ¿por qué no hacer que este ZK-EVM también esté disponible de forma nativa para rollups?

Este artículo describirá varias versiones del “ZK-EVM encapsulado”, analizando sus compensaciones, desafíos de diseño y razones para no ir en ciertas direcciones. Los beneficios de implementar la funcionalidad de un protocolo deben compararse con los beneficios de dejar que el ecosistema maneje las transacciones y mantener el protocolo subyacente simple.

¿Qué características clave queremos obtener del ZK-EVM encapsulado?

¿Cuáles son los atributos clave que podemos esperar del ZK-EVM empaquetado?

Función básica: Validar bloques ETH. La función de protocolo (que aún no se ha determinado si se trata de código de operación, precompilación o algún otro mecanismo) debe ser capaz de 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 ejecutar ese bloque sobre la raíz de preestado. Compatible con ETH multicliente de Workshop. Esto significa que queremos evitar un único sistema de atestación integrado y, en su lugar, permitir que diferentes clientes usen diferentes sistemas de atestación.

Esto también significa algunas cosas:

Requisitos de disponibilidad de datos: para cualquier ejecución de EVM que utilice pruebas ZK-EVM encapsuladas, queremos garantizar que los datos subyacentes se puedan usar para que los probadores que utilizan un sistema de atestación diferente puedan volver a certificar la ejecución y los clientes que confían en ese sistema de atestación puedan validar esas pruebas recién generadas.

Las pruebas residen fuera de las estructuras de datos de EVM y fragmentos:* La funcionalidad ZK-EVM realmente 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 probarse, a cuyo contenido se puede acceder mediante códigos de operación o precompilaciones, y las reglas de consenso del lado cliente comprueban la disponibilidad de los datos y la prueba de las notificaciones realizadas en el bloque, respectivamente.

Auditabilidad: Si se demuestra alguna ejecución, queremos que los datos subyacentes sean utilizables para que, si algo sale mal, tanto los usuarios como los desarrolladores puedan inspeccionarlo. De hecho, esto añade una razón más por la que los requisitos de disponibilidad de datos son importantes.

Capacidad de actualización: Si encontramos un error en una solución ZK-EVM en particular, queremos poder solucionarlo rápidamente. Esto significa que no hay necesidad de una bifurcación dura para solucionar el problema. Esto añade otra razón por la que las pruebas fuera de EVM y las estructuras de datos de bloques son importantes.

Uno de los atractivos de admitir “EVM aproximada” :**L2s es la capacidad de innovar en la capa de ejecución y escalar la EVM. Si una máquina virtual L2 es solo ligeramente diferente de la EVM, sería bueno que L2 pudiera usar el ZK-EVM nativo en el protocolo para las mismas partes que la EVM y solo confiar en su propio código para manejar las diferentes partes. Esto se puede lograr mediante el diseño de una función ZK-EVM que permita a la persona que llama especificar un campo de bits, un código de operación o una lista de direcciones, que será manejado por un formulario proporcionado externamente en lugar de la propia EVM. También podemos hacer que el costo del gas sea personalizable hasta cierto punto.

Sistemas multicliente “abiertos” vs. “cerrados”

La “mentalidad multicliente” es probablemente el requisito más controvertido de esta lista. Una opción sería abandonar el multicliente y centrarse en un esquema ZK-SNARK, lo que simplificaría el diseño. Pero a costa de un “cambio filosófico” mayor en ETH Workshop (ya que esto es abandonar efectivamente la mentalidad multicliente de larga data de ETH Workshop) e introducir un mayor riesgo. En el futuro a largo plazo, por ejemplo, cuando las técnicas formales de verificación mejoren, puede ser mejor seguir esta ruta, pero por ahora parece demasiado arriesgado.

Otra opción es un sistema multicliente cerrado con un conjunto fijo de sistemas de atestación que se conoce dentro del protocolo. Por ejemplo, podríamos decidir usar tres ZK-EVM: PSE ZK-EVM, Polygon ZK-EVM y Kakarot. Un bloque necesita pruebas de al menos dos de estos tres para ser válido. Esto es mejor que un sistema de prueba única, pero hace que el sistema sea menos adaptable debido a que los usuarios tienen que mantener validadores para cada sistema de prueba que exista, habrá un proceso de gobernanza inevitable para incorporar nuevos sistemas de prueba, etc.

Esto me empuja a preferir un sistema multicliente abierto en el que las pruebas se colocan “fuera del bloque” y los clientes las verifican por separado. Los usuarios individuales usarán cualquier cliente que deseen para validar un bloque, y podrán hacerlo siempre que 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 costo más complejo, como veremos.

¿Qué características clave queremos en 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 es posible diseñar un protocolo asíncrono con funcionalidad ZK-EVM incorporada donde cada reclamo solo devuelve resultados después 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, de modo que lo que sucede en cada bloque sea autosuficiente.

Si bien hoy en día se tarda minutos u horas en generar una prueba para un bloque ETH, sabemos que no hay ninguna razón teórica para evitar la paralelización masiva: siempre podemos ensamblar suficientes GPU para probar las diferentes partes de la ejecución del bloque por separado y luego usar SNARK recursivos para juntar esas pruebas. Además, el proceso de prueba se puede optimizar aún más a través de la aceleración de hardware de FPGA y ASIC. Sin embargo, llegar allí es un desafío de ingeniería que no debe subestimarse.

¿Cómo se ve exactamente la función ZK-EVM en el protocolo?

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

clase ZKEVMClaimTransaction(Container):
pre_state_root: bytes 32
post_state_root: bytes 32
transacción_and_witness_blob_pointers: Lista[VersionedHash]
…

Al igual que con EIP-4844, el objeto pasado en el mempool es una versión modificada de la transacción:

clase ZKEvmClaimNetworkTransaction(Container):
pre_state_root: bytes 32
post_state_root: bytes 32
prueba: bytes
transacción_and_witness_blobs: List[Bytes[FIELD_ELEMENTS_PER_BLOB * 31 ]]

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 declaradas en un bloque.

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

En la capa de consenso, hemos agregado una regla de validación que solo aceptará un bloque si el cliente ve una prueba válida de cada notificación en el bloque. La prueba debe ser una concatenación de la prueba ZK-SNARK, serializada como un par de transacciones_and_witness_blobs, y pre_state_root válida con (i) y el testigo (ii) genera la publicación correcta_state_root. (Bloquear, Testigo) Potencialmente, los clientes pueden optar por esperar a M-de-N para varios tipos de pruebas.

Una nota aquí es que la ejecución del bloque en sí misma se puede considerar simplemente como un triplete que debe comprobarse junto con los tripletes proporcionados en el objeto ZKEVMClaimTransaction (σpre, σpost, Proof).

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.

Validación y revalidació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 la ejecución de un bloque de ETH en menos de 5 segundos, y que para cada sistema de prueba, hay suficientes voluntarios independientes que ejecutan hardware para generar pruebas.

Desafortunadamente, dado que los sistemas de certificación independientes no están integrados, no pueden ser incentivados en el protocolo, sin embargo, anticipamos que el costo de ejecutar un probador es menor en comparación con el costo de la investigación y el desarrollo, por lo que simplemente podemos usar un organismo genérico para financiar bienes públicos para los probadores.

Supongamos que alguien publica una ZKEvmClaimNetworkTransaction, pero solo publica una versión de la prueba ZK-EVM de PSE. El nodo de prueba de Polygon ZK-EVM ve esto y utiliza la prueba de Polygon ZK-EVM para calcular y volver a publicar el objeto.

Esto aumenta el retraso máximo total entre el nodo honesto más antiguo que acepta un bloque y el nodo honesto más nuevo que acepta el mismo bloque δ: 2 δ+Tprove (asumiendo Tprove<5 s).

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

Extensión: Soporte para “EVM aproximada”

Un objetivo ideal para la función ZK-EVM es admitir “EVM aproximada”: es decir, una EVM con alguna funcionalidad adicional incorporada. Esto podría incluir una nueva precompilación, nuevos códigos de operación o incluso opciones en las que el contrato se puede escribir en una EVM o en una máquina virtual completamente diferente (por ejemplo, como 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 hacer:

• Mesa de gas personalizada (los usuarios no pueden reducir los costos de gas, pero pueden aumentarlos)
• Deshabilitar ciertos códigos de operación
• Establecer el número de bloque (esto implicará diferentes reglas dependiendo de la bifurcación dura)
• Establezca un indicador que active un conjunto completo de cambios de EVM que se han normalizado para el uso de L2 en lugar del uso de L1, u otros cambios más simples

Para permitir que los usuarios agreguen nuevas características de una manera más abierta, mediante la introducción de una nueva precompilación (o código de operación), podemos incluir un registro de entrada/salida precompilado en el blob de ZKEVMClaimNetworkTransaction:

clase PrecompileInputOutputTran(Container):
usado_precompile_addresses: Lista[Address]
entradas_commitments: Lista[VersionedHash]
salidas: Lista[Bytes]

La ejecución de EVM se modificará de la siguiente manera. Inicialice una matriz de entrada 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 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 prometido al serializar el SSZ en la entrada. El propósito de exponer las entradas_commitments es facilitar a los SNARK externos la prueba de la relación entre las entradas y las salidas.

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. La ejecución de EVM ya ha generado la entrada para ellos, por lo que solo necesitan verificar si la entrada generada coincide con la entrada reclamada, lo que solo requiere una verificación de hash. Sin embargo, el resultado debe proporcionarse en su totalidad y, por lo tanto, deben ser datos utilizables.

Otra característica útil podría ser permitir “transacciones privilegiadas” que se pueden invocar desde cualquier cuenta del remitente. Estas transacciones se pueden ejecutar entre otras dos transacciones o como parte de otra transacción (y posiblemente con privilegios) cuando se invoca la precompilación. Esto se puede utilizar para permitir que los mecanismos que no son EVM se vuelvan a llamar a la EVM.

Este 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, este diseño es bastante poderoso. Por ejemplo:

• Al configurar used_precompile_addresses para incluir una lista de direcciones de cuenta normales con ciertas marcas en el estado, y hacer un SNARK para demostrar que está construido correctamente, puede admitir características de estilo Arbitrum Stylus donde el contrato se puede escribir en EVM o WASM (u otra máquina virtual). Las transacciones privilegiadas se pueden utilizar para permitir que las cuentas de WASM se devuelvan a llamar a la EVM.
• Al agregar una verificación externa para garantizar que los registros 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.
• Un ZK-EVM de tipo 4 se puede operar teniendo múltiples implementaciones: una que convierte directamente Solidity u otro lenguaje de alto nivel en una máquina virtual compatible con SNARK, y otra que lo compila en código EVM y lo ejecuta en el ZK-EVM incorporado. La segunda implementación (e inevitablemente más lenta) solo se puede ejecutar si el probador de errores envía una transacción que afirma que hay un error y cobra una recompensa si puede ofrecer que los dos manejan transacciones diferentes. Se puede lograr una máquina virtual asincrónica pura devolviendo cero a todas las llamadas y asignando las llamadas a las transacciones con privilegios agregadas al final del bloque.

Extensión: Compatibilidad con certificadores con estado

Uno de los desafíos con el diseño anterior es que es completamente apátrida, lo que lo hace ineficiente para los datos. En el caso de la compresión de datos ideal, los envíos ERC 20 que utilizan la compresión con estado pueden ser hasta 3 veces más eficientes en cuanto al espacio que la compresión de solo estado.

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

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

1. Requisitos σpre O bien está vacío, es una lista de datos disponibles con las claves y los valores declarados, o bien se ejecuta antes de un tiempo determinado σpost 。

2. Hacia ( σpre, σpost, Prueba ) Triple para agregar un recibo generado para el bloque R de los compromisos de BLOB. Cualquier compromiso de blob generado o usado anteriormente, incluidos los que representan bloques, testigos, recibos o incluso transacciones de blob EIP-4844 simples, puede tener algunas restricciones de tiempo a las que se puede hacer referencia en ZKEVMClaimTransaction y a las que se puede acceder durante su ejecución (posiblemente a través de una serie de instrucciones: "Se confirmará i Los bytes de N… N+k-1 se inserta en los datos chunk+witness J "）。

La opción 1 significa que, en lugar de tener incorporada la verificación de EVM sin estado, es mejor tener una cadena hija de EVM incorporada. Básicamente, la opción dos crea un algoritmo de compresión con estado integrado mínimo que usa un blob usado o generado anteriormente como diccionario. Ambos enfoques colocan una carga en el nodo de prueba, que es el único que necesita almacenar más información, y en el caso dos, es más fácil tener un límite de tiempo en esta carga que en el caso uno.

Parámetros para multi-cerversers cerrados y datos fuera de la cadena

Un sistema cerrado de múltiples probadores con un número fijo de pruebas en una estructura M-de-N evita gran parte de la complejidad anterior. En particular, un sistema cerrado de múltiples probadores no necesita 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, haciéndolas compatibles con las soluciones de plasma EVM.

Sin embargo, un sistema cerrado de múltiples probadores agrega complejidad a la gobernanza y elimina la auditabilidad, que son costos altos que deben sopesarse con estos beneficios.

Si incorporáramos ZK-EVM en él y lo convirtiéramos en una característica de protocolo, ¿cuál sería el papel de un “proyecto de capa 2”?

Las funciones de verificación de EVM implementadas actualmente por los propios equipos de Capa 2 serán manejadas por el protocolo, pero el proyecto de Capa 2 sigue siendo responsable de una serie de características importantes:

• Preconfirmación rápida: La finalidad de una sola ranura puede ralentizar las ranuras de la Capa 1, mientras que los proyectos de la Capa 2 ya están proporcionando a sus usuarios “preconfirmaciones” que están respaldadas por la propia seguridad de la Capa 2 con una latencia mucho menor que una sola ranura. Este servicio seguirá estando totalmente bajo la responsabilidad de la Capa 2.
• Estrategias de mitigación de MEV (Miner Extractable Value): Esto podría incluir mempools cifrados, selección de secuenciadores basada en la reputación y otras características que los de capa 1 son reacios a implementar.
• Extensiones a la EVM: Los proyectos de capa 2 pueden proporcionar extensiones significativas a la EVM para sus usuarios. Esto incluye una “EVM aproximada” y enfoques fundamentalmente diferentes, como el soporte WASM de Arbitrum Stylus y el lenguaje Cairo compatible con SNARK. • Conveniencia para usuarios y desarrolladores: Los equipos de capa 2 han hecho mucho para atraer usuarios y proyectos a su ecosistema y hacerlos sentir bienvenidos; se les compensa capturando MEV y cargos de congestión dentro de su red. Esta relación llegó para quedarse.