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, Co-Director Ejecutivo de la Fundación Ethereum, describe el trabajo de ingeniería necesario en los clientes de ejecución y consenso de Ethereum, además de nueva infraestructura de pruebas y procesos de seguridad.
zkEVM en L1 – el planhttps://t.co/KLz7PoH6q9
— Tomasz K. Stańczak (@tkstanczak) January 15, 2026
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 suelen verificar un bloque reejecutando las transacciones y comparando los 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 pipeline previsto en términos sencillos: un cliente de ejecución produce un paquete compacto de "testimonio" (witness) 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 reejecutarla. El plan exige un formato de testimonio formal en las especificaciones de ejecución de Ethereum, pruebas de conformidad y un endpoint RPC estandarizado. Señala que el endpoint debug_executionWitness actual ya "está siendo utilizado en producción por Optimism’s Kona", mientras sugiere que podría ser necesario un endpoint más amigable para zk.
Una dependencia clave es agregar un mejor seguimiento de las partes del estado que un bloque toca, a través de Listas de Acceso a Nivel de Bloque (BALs). El documento indica que, a partir de noviembre de 2025, este trabajo no se consideró lo suficientemente urgente como 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 testimonio. El plan enfatiza compilaciones reproducibles y compilar para objetivos estandarizados para que las suposiciones sean explícitas y verificables.
Más allá del código específico de Ethereum, el plan busca estandarizar la interfaz entre las zkVMs y el programa invitado: objetivos comunes, formas comunes de acceder a precompilaciones e E/S, y suposiciones acordadas sobre cómo se cargan y ejecutan los programas.
En el lado del consenso, la hoja de ruta exige cambios para que los clientes de consenso puedan aceptar pruebas zk como parte de la validación de bloques de beacon, con especificaciones acompañantes, vectores de prueba y un plan de implementación interna. El documento también destaca la importancia de la disponibilidad del payload de ejecución, incluyendo un enfoque que podría involucrar "poner el bloque en blobs".
La propuesta trata la generación de pruebas tanto como un problema operativo como de protocolo. Incluye hitos para integrar zkVMs en herramientas de la EF como Ethproofs y Ere, probar configuraciones de GPU (incluyendo "zkboost"), y rastrear la confiabilidad y los cuellos de botella.
La evaluación comparativa (benchmarking) se enmarca como un trabajo continuo, con objetivos explícitos como medir el tiempo de generación del testimonio, el tiempo de creación y verificación de la prueba, y el impacto en la red de la propagación de pruebas. Esas mediciones podrían alimentar futuras propuestas de reprecio de gas para cargas de trabajo intensivas en zk.
La seguridad también está marcada como perpetua, con planes para especificaciones formales, monitoreo, controles de la cadena de suministro como compilaciones reproducibles y firma de artefactos, y un modelo de confianza y amenazas documentado. El documento propone un "marco de go/no-go" para decidir cuándo los sistemas de prueba están lo suficientemente maduros para un uso más amplio.
Una dependencia externa se destaca: ePBS, que el documento describe como necesaria para darles más tiempo a los probadores. Sin ello, el plan dice que el probador tiene "1-2 segundos" para crear una prueba; con ello, "6-9 segundos". El documento agrega un marco 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", con objetivo para mediados de 2026.
Si se cumplen estos hitos, Ethereum avanzaría hacia la validación basada en pruebas como una opción práctica en L1, mientras que el tiempo y la complejidad operativa de la prueba siguen siendo los factores limitantes.
Al cierre de esta edición, ETH cotizaba a $3,300.
