Agrupaciones de conocimiento cero

Los rollups de conocimiento cero (ZK-rollups) son soluciones de escalabilidad de capa 2 que aumentan el rendimiento en la red principal de Ethereum al mover la computación y el almacenamiento del estado fuera de la cadena. Los ZK-rollups pueden procesar miles de transacciones en un lote y luego pasar solo algunos de los datos mínimos y necesarios hacia la red principal. Estos datos en resúmen, definen los cambios que deben hacerse en Ethereum, y realizar pruebas criptográficas de que esos cambios y resultados finales son correctos.

Requisitos previos

Debería haber leído y entendido nuestra página sobre el escalado de Ethereum y la capa 2.

¿Qué son las pruebas de conocimiento cero (ZK)?

Los rollups de conocimiento cero (ZK-rollups) agrupan (o «enrollan») las transacciones en lotes que se ejecutan fuera de la cadena. La computación fuera de la cadena reduce la cantidad de datos que se deben registrar en la cadena de bloques. Los operadores de ZK-rollups presentan un resumen de los cambios necesarios para representar todas las transacciones en un lote en lugar de enviar cada transacción individualmente. También producen para demostrar la corrección de sus cambios.

El estado de los ZK-rollups se mantendrá en un contrato inteligente desplegado en la red Ethereum. Para actualizar este estado, los nodos desplegables de ZK-rollup deberán presentar una prueba de su validez para la verificación. Como se ha mencionado, la prueba de validez es una garantía criptográfica de que el cambio de estado propuesto por el rollup es realmente el resultado verdadero de la ejecución de las transacciones. Esto significa que los ZK-rollups solo necesitan proporcionar pruebas de validez para finalizar las transacciones en Ethereum, en lugar de publicar todos los datos de la transacción en la cadena como los rollups optimistas.

La ejecucíon tardará poco tiempo, ya que cuando se mueven los activos de un ZK-rollup a Ethereum, las transacciones se ejecutan una vez validada y verificada su validez. Por el contrario, la retirada de fondos de los rollups optimistas está sujeta a una demora para permitir que cualquiera pueda impugnar la transacción de salida con una .

Los ZK-rollups escriben las transacciones en Ethereum como calldata. calldata es donde se almacenan los datos que se incluyen en las llamadas externas a las funciones de los contratos inteligentes. La información en calldata se publica en la cadena de bloques, lo que permite que cualquiera pueda reconstruir el estado del rollup de forma independiente. Los ZK-rollup utilizan técnicas de compresión para reducir los datos de las transacciones: por ejemplo, las cuentas están representadas por un índice en lugar de una dirección, que ahorra unos 28 bytes en datos. La publicación de datos dentro de la cadena tiene un coste significativo para los rollups, por lo que la compresión de datos puede reducir las tarifas para los usuarios.

¿Cómo interactúan los ZK-rollups con Ethereum?

Una cadena de ZK-rollup es un protocolo fuera de la cadena que opera sobre la cadena de bloques de Ethereum y se gestiona mediante contratos inteligentes dentro de la misma. Los ZK-rollups ejecutan transacciones fuera de la red principal, pero periódicamente registran lotes de transacciones fuera de la cadena a un contrato rollup dentro de la cadena de bloques. Este registro de transacciones es inmutable, al igual que ocurre en la cadena de bloque de Ethereum y forma la cadena de ZK-rollups.

La arquitectura central de los ZK-rollups está compuesta por los siguientes componentes:

Contratos en cadena: como se ha mencionado, el protocolo del ZK-rollup se controla mediante contratos inteligentes que se ejecutan en Ethereum. Esto incluye el contrato principal que almacena los bloques acumulables, realiza un seguimiento de los depósitos y supervisa las actualizaciones del estado. Otro contrato en cadena (el contrato verificador) verifica las pruebas de conocimiento cero enviadas por los productores de bloques. Por lo tanto, Ethereum sirve como capa base o «capa 1» para el ZK-rollup.
Máquina virtual fuera de la cadena (VM): aunque el protocolo ZK-rollup reside en Ethereum, la ejecución de la transacción y el almacenamiento del estado se producen en una máquina virtual independiente de la EVM. Esta VM fuera de la cadena es el entorno de ejecución para transacciones en el ZK-rollup y sirve como capa secundaria (o capa 2) para el protocolo ZK-rollup. Las pruebas de validez verificadas en la red principal de Ethereum garantizan la corrección de las transiciones de estado en la VM fuera de la cadena.

ZK-rollups son «soluciones de escalabilidad híbrida»: protocolos fuera de la cadena que operan de forma independiente, pero aplican la seguridad de Ethereum. Específicamente, la red Ethereum impone la validez de las actualizaciones de estado en el ZK-rollup y garantiza la disponibilidad de datos detrás de cada actualización del estado del rollup. Como resultado, los ZK-rollups son considerablemente más seguros que las soluciones de escalabilidad puramente fuera de la cadena, como las cadenas laterales, que son responsables de sus propias propiedades de seguridad, o los validiums, que también verifican las transacciones en Ethereum con pruebas de validez, pero almacenan los datos de las transacciones en otro lugar.

Los ZK-rollups se basan en el protocolo principal de Ethereum para lo siguiente:

Disponibilidad de los datos

ZK-rollups publica datos de estado para cada transacción procesada fuera de la cadena a Ethereum. Con estos datos, es posible que las personas o las empresas reproduzcan el estado del rollup y validen la cadena por sí mismas. Ethereum pone estos datos a disposición de todos los participantes de la red como calldata.

ZK-rollups no necesitan publicar muchos datos de transacciones en cadena, porque las pruebas de validez ya verifican la autenticidad de las transiciones de estado. Sin embargo, el almacenamiento de datos en cadena sigue siendo importante porque permite la verificación independiente sin permiso del estado de la cadena L2, lo que a su vez permite a cualquiera enviar lotes de transacciones, evitando que los operadores maliciosos censuren o congelen la cadena.

Se requiere en cadena para que los usuarios interactúen con el rollup. Sin acceso a los datos de estado, los usuarios no pueden consultar el saldo de su cuenta o iniciar transacciones (por ejemplo, retiradas) que se basen en la información sobre el estado.

Finalidad de la transacción

Ethereum actúa como una capa de liquidación para los ZK-rollups: las transacciones L2 se finalizan solo si el contrato L1 acepta la prueba de validez. Esto elimina el riesgo de que los operadores maliciosos corrompan la cadena (por ejemplo, el robo de fondos rollup), ya que cada transacción debe aprobarse en la red principal. Además, Ethereum garantiza que las operaciones de los usuarios no se pueden revertir una vez finalizadas en L1.

Resistencia a la censura

La mayoría de los ZK-rollups utilizan un «supernodo» (el operador) para ejecutar transacciones, producir lotes y enviar bloques a L1. Si bien esto garantiza la eficiencia, aumenta el riesgo de censura: los operadores maliciosos de ZK-rollup pueden censurar a los usuarios al negarse a incluir sus transacciones en lotes.

Como medida de seguridad, los ZK-rollups permiten a los usuarios enviar transacciones directamente al contrato de rollup en la red principal si creen que están siendo censurados por el operador. Esto permite a los usuarios forzar una salida del ZK-rollup a Ethereum sin tener que depender del permiso del operador.

¿Cómo funcionan los ZK-rollups?

Transacciones

Los usuarios del ZK-rollup firman las transacciones y las envían a los operadores de L2 para su procesamiento e inclusión en el siguiente lote. En algunos casos, el operador es una entidad centralizada, llamada secuenciador, que ejecuta transacciones, las añade en lotes y las envía a L1. El secuenciador de este sistema es la única entidad a la que se le permite producir bloques L2 y añadir transacciones acumuladas al contrato de ZK-rollup.

Otros ZK-rollups pueden rotar el rol de operador utilizando un conjunto de validadores de prueba de participación. Los posibles operadores depositan fondos en el contrato de rollup. El tamaño de cada participación influye en las posibilidades que el participante tiene de ser seleccionado para producir el próximo lote de rollup. La participación del operador se puede reducir si actúa de forma maliciosa, lo que los incentiva a publicar bloques válidos.

Cómo publican los ZK-rollups los datos de las transacciones en Ethereum

Como se ha explicado, los datos de las transacciones se publican en Ethereum como calldata. calldata es un área de datos en un contrato inteligente que se utiliza para pasar argumentos a una función y se comporta de forma similar a la memoria. Aunque calldata no se almacena como parte del estado de Ethereum, persiste en la cadena como parte de los registros de historialopens in a new tab de la cadena de Ethereum. calldata no afecta al estado de Ethereum, lo que lo convierte en una forma barata de almacenar datos en la cadena.

La palabra clave calldata a menudo identifica el método del contrato inteligente al que llama una transacción y contiene las entradas para el método en forma de una secuencia arbitraria de bytes. Los ZK-rollups utilizan calldata para publicar datos de transacciones comprimidos en la cadena; el operador del rollup simplemente añade un nuevo lote llamando a la función requerida en el contrato del rollup y pasa los datos comprimidos como argumentos de la función. Esto ayuda a reducir los costes de los usuarios, ya que gran parte de las tarifas de los rollups se destinan al almacenamiento de datos de transacciones en la cadena.

Compromisos de estado

El estado del ZK-rollup, que incluye cuentas y saldos de la capa 2, se representa como un árbol de Merkle. Un hash criptográfico de la raíz del árbol Merkle (raíz Merkle) se almacena en el contrato en la cadena, lo que permite que el protocolo rollup rastree los cambios en el estado del ZK-rollup.

Las transacciones del rollup pasan a un nuevo estado después de la ejecución de un nuevo conjunto de transacciones. El operador que inició la transición de estado debe calcular una nueva raíz de estado y someterse al contrato en la cadena. Si el contrato de verificador autentica la prueba de validez asociada con el lote, la nueva raíz de Merkle se convierte en la raíz de estado canónico del ZK-rollup.

Además de calcular las raíces de estado, el operador ZK-rollup también crea una raíz de lote, la raíz de un árbol de Merkle que comprende todas las transacciones en un lote. Cuando se envía un nuevo lote, el contrato acumulable almacena la raíz del lote, lo que permite a los usuarios probar que una transacción (por ejemplo, una solicitud de retirada) se ha incluido en el lote. Los usuarios tendrán que proporcionar los detalles de la transacción, la raíz del lote y una prueba de Merkle que muestre la ruta de inclusión.

Pruebas de validez

La nueva raíz de estado que el operador de ZK-rollup envía al contrato L1 es el resultado de las actualizaciones del estado del rollup. Digamos que Alice envía 10 tókenes a Bob, el operador simplemente disminuye el saldo de Alice en 10 e incrementa el saldo de Bob en otros 10. A continuación, el operador hace un hash de los datos actualizados de la cuenta, reconstruye el árbol de Merkle del rollup y envía la nueva raíz de Merkle al contrato en cadena.

Pero el contrato de rollup no aceptará automáticamente el compromiso de estado propuesto hasta que el operador demuestre que la nueva raíz de Merkle es resultante de las actualizaciones correctas del estado del rollup. El operador de ZK-rollup hace esto produciendo una prueba de validez, un compromiso criptográfico sucinto que verifica la exactitud de las transacciones por lotes.

Las pruebas de validez permiten a las partes probar la exactitud de una declaración sin revelar la declaración en sí, por lo tanto, también se llaman pruebas de conocimiento cero. Los ZK-rollups utilizan pruebas de validez para confirmar la corrección de las transiciones de estado fuera de la cadena sin tener que volver a ejecutar transacciones en Ethereum. Estas pruebas pueden presentarse en forma de un ZK-SNARKopens in a new tab (argumento de conocimiento sucinto no interactivo de conocimiento cero) o un ZK-STARKopens in a new tab (argumento de conocimiento escalable y transparente de conocimiento cero).

Tanto los SNARK como los STARK ayudan a dar fe de la integridad de la computación fuera de la cadena en los ZK-rollups, aunque cada tipo de prueba tiene funcionalidades particulares.

ZK-SNARKs

Para que el protocolo ZK-SNARK funcione, es necesario crear una cadena de referencia común (CRS): el CRS proporciona parámetros públicos para probar y verificar las pruebas de validez. La seguridad del sistema de pruebas depende de la configuración del CRS; si la información utilizada para crear parámetros públicos cae en posesión de operadores maliciosos, pueden ser capaces de generar pruebas de falsa validez.

Algunos ZK-rollups intentan resolver este problema utilizando una ceremonia de computación multipartita (MPC)opens in a new tab, en la que participan personas de confianza, para generar parámetros públicos para el circuito ZK-SNARK. Cada parte contribuye con cierta aleatoriedad (conocido como «residuo tóxico») a la construcción del CRS, que deben destruir inmediatamente.

Las configuraciones de confianza se utilizan porque aumentan la seguridad de la configuración de CRS. Mientras un participante honesto destruya su aportación, la seguridad del sistema ZK-SNARK está garantizada. Aún así, este enfoque requiere confiar en los involucrados para eliminar la aleatoriedad de su muestra y no socavar las garantías de seguridad del sistema.

Dejando a un lado las suposiciones de confianza, los ZK-SNARK son populares por sus pequeños tamaños de prueba y su verificación en tiempo constante. Como la verificación de pruebas en L1 constituye el mayor coste a la hora de operar un ZK-rollup, los L2 utilizan ZK-SNARKs para generar pruebas que se pueden verificar de forma rápida y económica en la red principal.

ZK-STARKs

Al igual que los ZK-SNARK, los ZK-STARK demuestran la validez de los cálculos fuera de la cadena sin revelar las entradas de datos. Sin embargo, los ZK-STARK se consideran una mejora de los ZK-SNARK debido a su escalabilidad y transparencia.

Los ZK-STARK son «transparentes», ya que pueden funcionar sin la configuración de confianza de una cadena de referencia común (CRS). En su lugar, los ZK-STARK se basan en la aleatoriedad verificable públicamente para establecer parámetros para generar y verificar pruebas.

Los ZK-STARKs también proporcionan más escalabilidad porque el tiempo necesario para probar y verificar las pruebas de validez aumenta de forma cuasilineal en relación con la complejidad de la computación subyacente. Con los ZK-SNARKs, los tiempos de prueba y verificación escalan de forma lineal en relación con el tamaño de la computación subyacente. Esto significa que los ZK-STARK requieren menos tiempo que los ZK-SNARK para probar y verificar cuando se trata de grandes conjuntos de datos, lo que los hace útiles para aplicaciones de gran volumen.

Los ZK-STARK también son seguros contra los ordenadores cuánticos, mientras que se cree que la criptografía de curva elíptica (ECC) utilizada en los ZK-SNARK es susceptible a los ataques de computación cuántica. La desventaja de los ZK-STARK es que producen unos tamaños de prueba más grandes que son más caros de verificar en Ethereum.

¿Cómo funcionan las pruebas de validez en los ZK-rollups?

Generación de pruebas

Antes de aceptar transacciones, el operador realizará las comprobaciones habituales. Esto incluye confirmar que:

Las cuentas del remitente y del receptor son parte del árbol de estado.
El remitente tiene fondos suficientes para procesar la transacción.
La transacción es correcta y coincide con la clave pública del remitente en el rollup.
El nonce del remitente es correcto, etc.

Una vez que el nodo ZK-rollup tiene suficientes transacciones, las añade en un lote y compila las entradas para que el circuito de prueba se compile en una breve prueba de ZK. Esto incluye:

Una raíz de árbol de Merkle que comprende todas las transacciones del lote.
Pruebas de Merkle para transacciones que demuestren su inclusión en el lote.
Pruebas de Merkle para cada par remitente-receptor en las transacciones para demostrar que esas cuentas son parte del árbol del estado del rollup.
Un conjunto de raíces de estado intermedio, derivadas de la actualización de la raíz de estado después de aplicar actualizaciones de estado para cada transacción (es decir, disminución de las cuentas de remitente y aumento de las cuentas de destinatario).

El circuito de prueba calcula la prueba de validez «en bucle» sobre cada transacción y realiza las mismas comprobaciones que el operador completó antes de procesar la transacción. En primer lugar, verifica que la cuenta del remitente sea parte de la raíz de estado existente utilizando la prueba de Merkle proporcionada. Luego reduce el saldo del remitente, aumenta su nonce, hace un hash de los datos actualizados de la cuenta y los combina con la prueba de Merkle para generar una nueva raíz de Merkle.

Esta raíz de Merkle refleja el único cambio en el estado del ZK-rollup: un cambio en el equilibrio y el nonce del remitente. Esto es posible porque la prueba de Merkle utilizada para probar la existencia de la cuenta se utiliza para derivar la nueva raíz de estado.

El circuito de prueba realiza el mismo proceso en la cuenta del receptor. Comprueba si la cuenta del receptor existe bajo la raíz de estado intermedio (utilizando la prueba de Merkle), aumenta su saldo, repite los datos de la cuenta y los combina con la prueba de Merkle para generar una nueva raíz de estado.

El proceso se repite para cada transacción; cada «bucle» crea una nueva raíz de estado al actualizar la cuenta del remitente y una nueva raíz posterior al actualizar la cuenta del receptor. Tal y como se ha explicado, cada actualización de la raíz de estado representa una parte del cambio del árbol de estado del rollup.

El circuito de prueba ZK se repite en todo el lote de transacciones, verificando la secuencia de actualizaciones que dan como resultado una raíz de estado final después de que se ejecute la última transacción. La última raíz de Merkle calculada se convierte en la raíz de estado canónica más reciente del ZK-rollup.

Verificación de la prueba

Después de que el circuito de prueba verifique la exactitud de las actualizaciones de estado, el operador L2 presenta la prueba de validez calculada al contrato de verificación en L1. El circuito de verificación del contrato verifica la validez de la prueba y también comprueba las entradas públicas que forman parte de la prueba:

Raíz del estado previo: la raíz del estado anterior del ZK-rollup (es decir, antes de que se ejecutaran las transacciones por lotes), que refleja el último estado válido conocido de la cadena de capa 2.
Raíz del estado posterior: la nueva raíz del estado del ZK-rollup (es decir, después de la ejecución de las transacciones por lotes), que refleja el estado más reciente de la cadena de capa 2. La raíz posterior al estado es la raíz final derivada después de aplicar actualizaciones de estado en el circuito de prueba.
Raíz de lote: la raíz de Merkle del lote, que se obtiene merklizando las transacciones del lote y aplicando una función hash a la raíz del árbol.
Entradas de la transacción: datos asociados a las transacciones ejecutadas como parte del lote enviado.

Si la prueba satisface el circuito (es decir, es válida), significa que existe una secuencia de transacciones válidas que hacen la transición del rollup del estado anterior (criptada criptográficamente por la raíz preestado) a un nuevo estado (criptada criptográficamente por la raíz posterior al estado). Si la raíz de preestado coincide con la raíz almacenada en el contrato de rollup, y la prueba es válida, el contrato de rollup toma la raíz de posestado de la prueba y actualiza su árbol de estado para reflejar el estado cambiado del rollup.

Entradas y salidas

Los usuarios entran en el ZK-rollup depositando tókenes en el contrato del rollup desplegado en la cadena L1. Esta transacción se pone en la cola, ya que solo los operadores pueden enviar transacciones al contrato de rollup.

Si la cola de depósitos pendientes comienza a llenarse, el operador de ZK-rollup tomará las transacciones de depósito y las enviará al contrato de rollup. Una vez que los fondos del usuario estén en el rollup, puede comenzar a realizar transacciones enviándolas al operador para que las procese. Los usuarios pueden verificar los saldos en el rollup haciendo hash de los datos de su cuenta, enviando el hash al contrato del rollup y proporcionando una prueba de Merkle para verificar con la raíz del estado actual.

Una retirada de un ZK-rollup a L1 es sencillo. El usuario inicia la transacción de salida enviando sus activos en el rollup a una cuenta específica para que se quemen. Si el operador incluye la transacción en el siguiente lote, el usuario puede enviar una solicitud de retirada al contrato en cadena. Esta solicitud de retirada incluirá lo siguiente:

Prueba de Merkle que demuestra la inclusión de la transacción del usuario en la cuenta de quema en un lote de transacciones
Datos de la transacción
Raíz de lote
Dirección L1 para recibir fondos depositados

El contrato rollup hace un hash de los datos de la transacción, comprueba si la raíz del lote existe y utiliza la prueba de Merkle para comprobar si el hash de la transacción es parte de la raíz del lote. Después, el contrato ejecuta la transacción de salida y envía los fondos a la dirección elegida por el usuario en L1.

Los ZK-rollups y la compatibilidad con la EVM

A diferencia de los rollups optimistas, los ZK-rollups no son compatibles de forma nativa con la Máquina virtual de Ethereum (EVM). Es más difícil demostrar el cálculo EVM de propósito general en circuitos y requiere más recursos que demostrar cálculos sencillos (como la transferencia de tókenes descrita anteriormente).

Sin embargo, los avances en la tecnología de conocimiento ceroopens in a new tab están despertando un interés renovado en envolver la computación de la EVM en pruebas de conocimiento cero. Estos esfuerzos están orientados a crear una implementación de EVM de conocimiento cero (zkEVM) que pueda verificar de manera eficiente la corrección de la ejecución del programa. Un zkEVM recrea los códigos de operación EVM existentes para la prueba/verificación en los circuitos, lo que permite ejecutar contratos inteligentes.

Al igual que el EVM, zkEVM transita entre estados después de que se realice el cálculo en algunas entradas. La diferencia es que el zkEVM también crea pruebas de conocimiento cero para verificar la corrección de cada paso de la ejecución del programa. Las pruebas de validez podrían verificar la exactitud de las operaciones que tocan el estado de la máquina virtual (memoría, pila, almacenamiento) y el cálculo en sí (es decir, ¿la operación utilizó los códigos de operación correctos y los ejecutó correctamente?).

Se espera que la introducción de los ZK-rollups compatibles con EVM ayude a los desarrolladores a aprovechar las garantías de escalabilidad y seguridad de las pruebas de conocimiento cero. Lo que es más importante, la compatibilidad con la infraestructura nativa de Ethereum significa que los desarrolladores pueden crear dapps compatibles con ZK utilizando herramientas e idiomas familiares (y probados en la práctica).

¿Cómo funcionan las tarifas de ZK-rollup?

La cantidad que los usuarios pagan por las transacciones en los ZK-rollups depende de la tarifa de gas, al igual que en la red principal de Ethereum. Sin embargo, las tarifas de gas funcionan de manera diferente en L2 y están influidas por los siguientes costes:

Escritura de estado: existe un coste fijo por escribir en el estado de Ethereum (es decir, enviar una transacción en la cadena de bloques de Ethereum). Los ZK-rollups reducen este coste al agrupar las transacciones y distribuir los costes fijos entre múltiples usuarios.
Publicación de datos: los ZK-rollups publican los datos de estado de cada transacción en Ethereum como calldata. Los costes de calldata se rigen actualmente por la EIP-1559opens in a new tab, que estipula un coste de 16 de gas para los bytes que no son cero y 4 de gas para los bytes que son cero de calldata, respectivamente. El coste que se paga en cada transacción depende de la cantidad de calldata que se necesite publicar en la cadena para ella.
Comisiones del operador de la capa 2: es el importe que se paga al operador del rollup como compensación por los costes computacionales en los que se incurre al procesar las transacciones, de forma muy parecida a las "comisiones de prioridad (propinas)" de las transacciones en la red principal de Ethereum.
Generación y verificación de pruebas: los operadores de ZK-rollup deben producir pruebas de validez para los lotes de transacciones, lo cual consume muchos recursos. Verificar las pruebas de conocimiento cero en la red principal también cuesta gas (~ 500.000 gas).

Además de las transacciones por lotes, los ZK-rollups reducen las tarifas para los usuarios al comprimir los datos de las transacciones. Puede ver un resumen en tiempo realopens in a new tab de lo que cuesta usar los ZK-rollups de Ethereum.

¿Cómo se escalan los ZK-rollups a Ethereum?

Compresión de los datos de las transacciones

Los ZK-rollups amplían el rendimiento en la capa base de Ethereum llevando el cálculo fuera de la cadena, pero el verdadero impulso para la escalabilidad proviene de la compresión de los datos de las transacciones. El tamaño de bloque de Ethereum limita la cantidad de datos que puede contener cada bloque y, por extensión, el número de transacciones que se procesan por bloque. Al comprimir los datos relacionados con las transacciones, los ZK-rollups aumentan significativamente el número de transacciones procesadas por bloque.

Los ZK-rollups pueden comprimir los datos de las transacciones mejor que los rollups optimistas, ya que no tienen que publicar todos los datos necesarios para validar cada transacción. Solo tienen que publicar los datos mínimos necesarios para reconstruir el último estado de las cuentas y los saldos en la lista acumulada.

Pruebas recursivas

Una ventaja de las pruebas de conocimiento cero es que las pruebas pueden verificar otras pruebas. Por ejemplo, un solo ZK-SNARK puede verificar otros ZK-SNARK. Tales «pruebas de prueba» se llaman pruebas recursivas y aumentan drásticamente el rendimiento en los ZK-rollups.

Actualmente, las pruebas de validez se generan bloque por bloque y se envían al contrato L1 para su verificación. Sin embargo, la verificación de las pruebas de un solo bloque limita el rendimiento que pueden lograr los ZK-rollups, ya que solo se puede finalizar un bloque cuando el operador presenta una prueba.

Sin embargo, las pruebas recursivas permiten finalizar varios bloques con una prueba de validez. Esto se debe a que el circuito de prueba agrega recursivamente múltiples pruebas de bloque hasta que se crea una prueba final. El operador de L2 presenta esta prueba recursiva, y si el contrato la acepta, todos los bloques relevantes se finalizarán al instante. Con las pruebas recursivas, aumenta el número de transacciones de ZK-rollup que se pueden finalizar en Ethereum a intervalos.

Ventajas y desventajas de los ZK-rollups

Pros	Contras
Las pruebas de validez garantizan la corrección de las transacciones fuera de la cadena y evitan que los operadores ejecuten transiciones de estado no válidas.	El coste asociado con el cálculo y la verificación de las pruebas de validez es sustancial y puede aumentar las tarifas para los usuarios de rollup.
Ofrece una finalización de transacción más rápida, ya que las actualizaciones del estado se aprueban una vez que se verifican las pruebas de validez en L1.	Construir ZK-rollups compatibles con EVM es difícil debido a la complejidad de la tecnología de conocimiento cero.
Se basa en mecanismos criptográficos sin confianza para la seguridad, no en la honestidad de los actores incentivados como en el caso de los rollups optimistas.	La producción de pruebas de validez requiere hardware especializado, que puede fomentar el control centralizado de la cadena por parte de algunas partes.
Almacena los datos necesarios para recuperar el estado fuera de la cadena en L1, lo que garantiza la seguridad, la resistencia a la censura y la descentralización.	Los operadores centralizados (secuenciadores) pueden influir en el orden de las transacciones.
Los usuarios se benefician de una mayor eficiencia de capital y pueden retirar fondos de L2 sin demoras.	Los requisitos de hardware pueden reducir el número de participantes que pueden obligar a la cadena a progresar, aumentando el riesgo de que los operadores maliciosos congelen el estado del rollup y censuren a los usuarios.
No depende de las suposiciones de vitalidad y los usuarios no tienen que validar la cadena para proteger sus fondos.	Algunos sistemas de prueba (por ejemplo, ZK-SNARK) requieren una configuración de confianza que, si se maneja mal, podría comprometer el modelo de seguridad de un ZK-rollup.
Una mejor compresión de los datos puede ayudar a reducir los costes de publicación de `calldata` en Ethereum y minimizar las comisiones del rollup para los usuarios.

Una explicación visual de los ZK-rollups

Vea una explicación de Finematics de los ZK-rollups:

¿Quién está trabajando en un zkEVM?

Los proyectos que trabajan en zkEVM incluyen:

zkEVMopens in a new tab: un proyecto financiado por la Fundación Ethereum para desarrollar un ZK-rollup compatible con la EVM y un mecanismo para generar pruebas de validez para los bloques de Ethereum.
Polygon zkEVMopens in a new tab: es un ZK-rollup descentralizado en la red principal de Ethereum que funciona sobre una máquina virtual de Ethereum de conocimiento cero (zkEVM) que ejecuta transacciones de Ethereum de forma transparente, incluidos los contratos inteligentes con validaciones de prueba de conocimiento cero.
Scrollopens in a new tab: Scroll es una empresa de base tecnológica que trabaja en la creación de una solución nativa de capa 2 zkEVM para Ethereum.
Taikoopens in a new tab: Taiko es un ZK-rollup descentralizado y equivalente a Ethereum (un ZK-EVM de tipo 1opens in a new tab).
ZKsyncopens in a new tab: ZKsync Era es un ZK-rollup compatible con la EVM creado por Matter Labs e impulsado por su propia zkEVM.
Starknetopens in a new tab: StarkNet es una solución de escalabilidad de capa 2 compatible con la EVM y creada por StarkWare.
Morphopens in a new tab: Morph es una solución de escalabilidad de rollup híbrido que utiliza la prueba de conocimiento cero para abordar el problema del desafío de estado de la capa 2.
Lineaopens in a new tab: Linea es una capa 2 zkEVM equivalente a Ethereum, creada por Consensys y totalmente alineada con el ecosistema de Ethereum.