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

Autor: Ebunker

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

En toda la red, Vitalik y la Ethereum Foundation son quienes más han apostado por ZK. ZK es como el hijo menor de la familia Ethereum: recibe la mayor dedicació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, sin sacrificar la seguridad.

El cuello de botella en la mejora del 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: los bloques demasiado grandes suponen una carga pesada para los nodos.

Actualmente, Ethereum utiliza un modo 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 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 la ordenación MEV, el tiempo real que los validadores pueden dedicar a la verificación es de solo 4–8 segundos, dejando casi sin margen para manejar cargas mayores.

Ethereum tras la ZK-ización: de "verificación total por todos" a "verificación única por todos"

Si Ethereum L1 se ZK-iza completamente, el modo de verificación pasará de "verificación total por todos" a "verificación única por todos". En este modo, una vez ensamblado 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 ilustrativa es: antes, cuando solicitabas un permiso en DingTalk (enviabas 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.

Después de la ZK-ización, el sistema primero verifica que realmente tienes días de permiso, y luego emite una prueba unificada a todos los jefes (ZK); en ese momento, los jefes solo necesitan confiar y aprobar rápidamente (verificación única por todos).

Tras la ZK-izació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 ZK-ización.

Desafíos criptográficos y casos de estudio

Por supuesto, lograr todo esto requiere un enorme esfuerzo 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 centra 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 tarjetas 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 de los dispositivos de prueba ZK no supere los 100,000 dólares.

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

¿Por qué la "cobertura de 10 segundos" es tan importante? 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-izació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 hacia la ZK-ización;

Y para lograr la ZK-ización de manera elegante (generación de pruebas en menos de 10 segundos, costo de hardware inferior a 100,000 dólares), se necesita el esfuerzo conjunto de la comunidad criptográfica y el ecosistema de criptomonedas.

ZK es la dirección más compleja pero también la más determinante en la 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.