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

Título original: “¿Por qué Ethereum necesita ZK-VM: el camino definitivo para la escalabilidad?”

Autor original: Ebunker 中文

Entre las numerosas ideas para la escalabilidad de Ethereum, ZK es la dirección más compleja y crítica.

A lo largo de toda la red, V God y la Fundación Ethereum son los que más apuestan por ZK. ZK es un poco como el hijo más pequeño de la familia Ethereum, en el que se ha invertido más esfuerzo, pero su futuro es también el más incierto.

Hace unos días, la Fundación Ethereum publicó la hoja de ruta de Kohaku, que es un conjunto de planificación de componentes básicos para carteras de privacidad. La hoja de ruta enfatiza una vez más que muchas funciones centrales seguirán dependiendo de la implementación de ZK-EVM o ZK-VM.

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

La respuesta es simple: para mejorar el rendimiento, y no a expensas de la seguridad.

Cuello de botella en el rendimiento: verificación de todos y límite de GAS

Anteriormente mencionamos que la forma más efectiva de mejorar el rendimiento de Ethereum es aumentar el límite de GAS, es decir, hacer los bloques 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 “prueba de todos para todos”, es decir, todos los nodos deben verificar completamente cada bloque. Este mecanismo, aunque simple y seguro, tiene una alta redundancia.

Si se aumenta significativamente el límite de GAS, la carga de cálculo de cada nodo aumentará drásticamente.

Teniendo en cuenta que el intervalo de bloques de Ethereum es de solo 12 segundos, y que se necesita tiempo para la propagación de bloques y la ordenación de MEV, el tiempo real disponible para que los validadores verifiquen es de aproximadamente 4 a 8 segundos, casi no hay margen para manejar una carga mayor.

Ethereum después de ZK: de “todos verificados” a “todos verificados una vez”

Si se lleva a cabo la ZK completa de Ethereum L1, el modo de verificación pasará de “todos verifican todo” a “todos verifican uno”. En este modo, una vez que un bloque esté ensamblado, se generará primero una prueba ZK.

Las características de ZK son que la generación de pruebas 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 necesidad de ejecutar nuevamente todas las transacciones dentro del bloque.

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

Una metáfora ilustrativa es: en el pasado, al presentar un proceso de solicitud de licencia en DingTalk (enviar una transacción), necesitabas que cada líder (nodo) verificara uno por uno si aún tenías saldo de días libres (verificación total), y solo después de que todos aprobaran, el proceso se completaba.

Una vez que se implementa ZK, el sistema primero verifica que efectivamente tienes vacaciones, y luego emite un comprobante unificado a todos los líderes (ZK). En este momento, los líderes solo necesitan confiar y aprobar rápidamente (una verificación para todos).

Después de la transformación ZK, todavía solicitas el proceso de permiso (enviar una transacción), el sistema descubre que tienes días de vacaciones restantes, informa directamente a todos los líderes “esta persona tiene permiso”, y los líderes confían completamente en que el sistema no se equivocará (ZK), entonces la aprobación de los líderes es mucho más rápida (todos verificados).

Esta es la razón por la que Ethereum va a ser ZK.

Desafíos y casos de la criptografía

Por supuesto, la cantidad de trabajo para lograr todo esto es enorme y la dificultad criptográfica es muy alta, por lo tanto, Ethereum debe colaborar con equipos profesionales.

El protocolo Brevis mencionado por el investigador de la Fundación Ethereum, Justin, es uno de los casos líderes en este campo.

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

Según los datos de prueba, con un tamaño de bloque de 45M GAS en Ethereum, Brevis utiliza 64 GPU RTX 5090 y puede completar el 99.6% de la prueba de bloque en 12 segundos, de los cuales el 96.8% de los bloques pueden completar la generación de pruebas en 10 segundos.

Para mantener la descentralización, Ethereum requiere que el costo de los dispositivos de prueba ZK no supere los 100,000 dólares.

Aunque las GPU más avanzadas (como la H200 o la B200) pueden generar pruebas más rápido, eso aumentaría significativamente la barrera de entrada. El diseño actual de Brevis está justo en este límite.

¿Por qué es crucial la “cobertura de 10 segundos”? Porque los bloques de MEV generalmente se generan en 1-3 segundos, y los 10 segundos de tiempo de prueba completan exactamente el intervalo de bloque de 12 segundos.

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

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

Para aumentar de manera segura el límite de GAS, es necesario promover la ZK.

Para lograr elegantemente la ZKización (generar pruebas en menos de 10 segundos y con un costo de hardware inferior a 100,000 dólares), se requiere el esfuerzo conjunto de la comunidad criptográfica y el ecosistema cripto.

ZK es la dirección más compleja pero también la más determinista en la ruta de escalado de Ethereum.

No solo se trata de rendimiento, sino que es la solución definitiva que busca un equilibrio entre la seguridad y la descentralización en Ethereum.