Por qué Ethereum necesita ZK-VM: el camino definitivo para la escalabilidad

Autor: Ebunker

Entre las muchas ideas para la escalabilidad de Ethereum, ZK es la más compleja y también la más crucial.

En toda la red, Vitalik y la Ethereum Foundation son quienes más apuestan por ZK. ZK es como el hijo menor de la familia Ethereum: es en quien más se invierte, pero también el que tiene el futuro más incierto.

Hace unos días, la Ethereum Foundation publicó la hoja de ruta Kohaku, que es una planificación de los componentes básicos para billeteras privadas. La hoja de ruta vuelve a enfatizar que muchas funciones clave seguirán dependiendo de la implementación de ZK-EVM o ZK-VM.

Entonces, ¿por qué Ethereum necesita con tanta urgencia ZK-VM?

La respuesta es simple: para mejorar el rendimiento, pero sin sacrificar la seguridad.

El cuello de botella para mejorar el rendimiento: verificación total y límite de GAS

Como mencionamos antes, la forma más directa de mejorar el rendimiento de Ethereum es aumentar el límite de GAS, es decir, hacer que los bloques sean más grandes.

Pero el problema es que aumentar el límite de GAS tiene un costo: bloques demasiado grandes son una carga pesada para los nodos.

Actualmente, Ethereum utiliza un modelo de verificación llamado “verificación total por todos”, es decir, todos los nodos deben verificar completamente cada bloque. Este mecanismo es simple y seguro, pero muy redundante.

Si el límite de GAS aumenta significativamente, la carga de cálculo de cada nodo también se disparará.

Teniendo en cuenta que el intervalo entre bloques de Ethereum es de solo 12 segundos, y que parte de ese tiempo debe reservarse para la propagación de bloques y el ordenamiento MEV, el tiempo real que los validadores pueden usar para verificar es de solo 4 a 8 segundos, casi sin margen para manejar una carga mayor.

Ethereum tras la ZK: de “verificación total por todos” a “verificación única por todos”

Si Ethereum L1 se convierte completamente a ZK, el modelo de verificación pasará de “verificación total por todos” a “verificación única por todos”. En este modelo, cuando se ensambla un bloque, primero se genera una prueba ZK.

La característica de ZK es que la generación de la prueba es lenta, pero la verificación es extremadamente rápida. Por lo tanto, los nodos solo necesitan verificar una vez si la prueba es correcta, sin tener que ejecutar todas las transacciones del bloque repetidamente.

Esto significa que Ethereum puede aumentar significativamente el límite de GAS sin aumentar notablemente la carga de los nodos.

Una analogía sería: antes, cuando solicitabas un permiso en DingTalk (enviando una transacción), cada jefe (nodo) tenía que verificar uno por uno si te quedaban días de permiso (verificación total por todos), y solo después de la aprobación de todos el proceso seguía adelante.

Con ZK, el sistema primero verifica que realmente tienes días de permiso, y luego presenta una prueba a todos los jefes (ZK); en ese momento, los jefes solo tienen que confiar y aprobar rápidamente (verificación única por todos).

Después de ZK, sigues solicitando el permiso (enviando una transacción), el sistema detecta que tienes días disponibles y les informa directamente a los jefes “esta persona tiene permiso”, y los jefes confían plenamente en que el sistema no se equivoca (ZK), por lo que la aprobación es mucho más rápida (verificación única por todos).

Esta es la razón por la que Ethereum quiere implementar ZK.

Desafíos criptográficos y casos de estudio

Por supuesto, lograr todo esto requiere un enorme trabajo de ingeniería y un alto nivel de dificultad criptográfica, por lo que Ethereum debe colaborar con equipos especializados.

El investigador de la Ethereum Foundation, Justin, mencionó el protocolo Brevis, que es uno de los casos líderes en este campo actualmente.

Brevis se enfoca en ZK-VM, y su última tecnología, Pico Prism, es una de las soluciones más rápidas para generar pruebas ZK bajo ciertas condiciones.

Según los datos de prueba, con el tamaño actual de bloque de Ethereum de 45 M GAS, Brevis utiliza 64 GPU RTX 5090 y puede completar el 99,6% de las pruebas de bloque en 12 segundos, de las cuales el 96,8% se generan en menos de 10 segundos.

Para mantener la descentralización, Ethereum exige que el costo del equipo para pruebas ZK no supere los 100 mil dólares.

Aunque GPUs más avanzadas (como H 200 o B 200) pueden generar pruebas más rápido, eso aumentaría mucho la barrera de entrada. El diseño actual de Brevis se ajusta justo a este límite.

¿Por qué la “cobertura de 10 segundos” también es crucial? Porque los bloques MEV suelen generarse en 1–3 segundos, y sumando los 10 segundos de generación de pruebas, se llena justo el intervalo de 12 segundos entre bloques.

Resumen: la lógica del camino hacia la ZK de Ethereum

Si Ethereum quiere acelerar la mejora del rendimiento de L1, debe aumentar el límite de GAS;

Para aumentar el límite de GAS de forma segura, debe avanzar hacia la ZK;

Y para implementar ZK de manera elegante (generar pruebas en menos de 10 segundos, con un costo de hardware inferior a 100 mil dólares), se necesita el esfuerzo conjunto de la comunidad criptográfica y el ecosistema de criptografía.

ZK es la dirección más compleja pero también la más definida en la hoja de ruta de escalabilidad de Ethereum.

No solo se trata de rendimiento, sino que es la solución definitiva de Ethereum para buscar el equilibrio entre seguridad y descentralización.