La Fundación Ethereum Traza el Camino hacia las Pruebas zkEVM en la L1 de la Red Principal

La Fundación Ethereum ha publicado un plan paso a paso para permitir que la cadena principal de Ethereum valide bloques utilizando pruebas zkEVM, reduciendo la necesidad de que los validadores vuelvan a ejecutar cada cálculo por sí mismos. La propuesta, compartida a través de X el 15 de enero por Tomasz K. Stańczak, Codirector Ejecutivo de la Fundación Ethereum, detalla el trabajo de ingeniería necesario en los clientes de ejecución y consenso de Ethereum, además de nueva infraestructura de prueba y procesos de seguridad.

Ethereum L1 Avanza Hacia la Validación Basada en Pruebas zk

Ya en julio del año pasado, la Fundación Ethereum anunció su enfoque "zk-first". Hoy en día, los validadores de Ethereum normalmente verifican un bloque volviendo a ejecutar las transacciones y comparando resultados. El plan propone una alternativa: los validadores podrían verificar una prueba criptográfica de que la ejecución del bloque fue correcta.

El documento resume el proceso previsto en términos simples: un cliente de ejecución produce un paquete compacto de "testigo" para un bloque, un programa zkEVM estandarizado utiliza ese paquete para generar una prueba de ejecución correcta, y los clientes de consenso verifican esa prueba durante la validación del bloque.

El primer hito es crear un "ExecutionWitness", una estructura de datos por bloque que contiene la información necesaria para validar la ejecución sin volver a ejecutarla. El plan requiere un formato formal de testigo en las especificaciones de ejecución de Ethereum, pruebas de conformidad y un endpoint RPC estandarizado. Señala que el endpoint actual debug_executionWitness ya está "siendo utilizado en producción por Kona de Optimism", mientras sugiere que puede necesitarse un endpoint más amigable con zk.

Una dependencia clave es añadir un mejor seguimiento de qué partes del estado toca un bloque, mediante Listas de Acceso a Nivel de Bloque (BALs). El documento dice que hasta noviembre de 2025, este trabajo no fue tratado como lo suficientemente urgente para ser retroportado a forks anteriores.

El siguiente hito es un "programa invitado zkEVM", descrito como lógica de validación sin estado que verifica si un bloque produce una transición de estado válida cuando se combina con su testigo. El plan enfatiza compilaciones reproducibles y compilación a objetivos estandarizados para que las suposiciones sean explícitas y verificables.

Más allá del código específico de Ethereum, el plan pretende estandarizar la interfaz entre zkVMs y el programa invitado: objetivos comunes, formas comunes de acceder a precompilaciones y E/S, y supuestos acordados sobre cómo se cargan y ejecutan los programas.

En el lado del consenso, la hoja de ruta requiere cambios para que los clientes de consenso puedan aceptar pruebas zk como parte de la validación de bloques beacon, con especificaciones acompañantes, vectores de prueba y un plan de implementación interno. El documento también marca la disponibilidad de carga útil de ejecución como importante, incluyendo un enfoque que podría implicar "poner el bloque en blobs".

La propuesta trata la generación de pruebas como un problema operacional tanto como de protocolo. Incluye hitos para integrar zkVMs en herramientas de EF como Ethproofs y Ere, probar configuraciones de GPU (incluyendo "zkboost") y rastrear confiabilidad y cuellos de botella.

El benchmarking se enmarca como trabajo en curso, con objetivos explícitos como medir el tiempo de generación de testigos, tiempo de creación y verificación de pruebas, y el impacto en la red de la propagación de pruebas. Esas mediciones podrían alimentar futuras propuestas de reajuste de gas para cargas de trabajo pesadas en zk.

La seguridad también está marcada como perpetua, con planes para especificaciones formales, monitoreo, controles de cadena de suministro como compilaciones reproducibles y firma de artefactos, y un modelo documentado de confianza y amenazas. El documento propone un "marco go/no-go" para decidir cuándo los sistemas de prueba son lo suficientemente maduros para un uso más amplio.

Una dependencia externa destaca: ePBS, que el documento describe como necesaria para dar más tiempo a los probadores. Sin ella, el plan dice que el probador tiene "1-2 segundos" para crear una prueba; con ella, "6-9 segundos". El documento añade un encuadre de dos oraciones que captura la urgencia: "Este no es un proyecto en el que estemos trabajando. Sin embargo, es una optimización que necesitamos". Espera que ePBS se implemente en "Glamsterdam", previsto para mediados de 2026.

Si estos hitos se logran, Ethereum estaría avanzando hacia la validación basada en pruebas como una opción práctica en L1, mientras que el timing y la complejidad operacional de la prueba siguen siendo los factores limitantes.

Al momento de la publicación, ETH cotizaba a $3,300.