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

Entre las numerosas 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: recibe la mayor atención, pero su futuro es el 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 una billetera privada. La hoja de ruta enfatiza nuevamente 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 en la mejora del rendimiento: validació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: los bloques demasiado grandes son una carga pesada para los nodos.

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

Si el límite de GAS aumenta significativamente, la carga computacional 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 dedicar a la validación es de solo 4 a 8 segundos, dejando casi sin margen para manejar una carga mayor.

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

Si Ethereum L1 se ZKiza completamente, el modelo de validación pasará de “verificación total por todos” a “verificación única por todos”. En este modelo, una vez que un bloque está ensamblado, 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 repetidamente todas las transacciones dentro del bloque.

Esto significa que Ethereum puede aumentar significativamente el límite de GAS sin incrementar 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 aún tenías días de permiso disponibles (verificación total por todos), y solo después de la aprobación de todos el proceso se completaba.

Pero tras la ZKización, el sistema primero verifica que realmente tienes días de permiso, y luego emite una prueba (ZK) a todos los jefes, quienes solo necesitan confiar y aprobar rápidamente (verificación única por todos).

Después de la ZKización, sigues solicitando el permiso (enviando una transacción), el sistema detecta que tienes días disponibles y se lo comunica directamente a todos 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 busca la ZKización.

Desafíos criptográficos y casos de uso

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

El protocolo Brevis, mencionado por el investigador de la Ethereum Foundation Justin, 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 de bloque actual de Ethereum de 45M GAS, Brevis utiliza 64 GPU RTX 5090 y puede completar la prueba del 99,6% de los bloques en 12 segundos, y el 96,8% de los bloques puede generar la prueba en 10 segundos.

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

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

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

Resumen: la lógica del camino hacia la ZKización 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 en la ZKización;

Y para lograr una ZKización elegante (generación de pruebas en menos de 10 segundos, costo de hardware por debajo de 100 mil dólares), se requiere 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 determinante 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.