El investigador de Ethereum, ladislaus.eth, publicó un tutorial la semana pasada que explica cómo Ethereum planea pasar de volver a ejecutar cada transacción a verificar pruebas de conocimiento cero.
La publicación lo presenta como una “transformación silenciosa pero fundamental”, y el encuadre es preciso. No porque el trabajo sea secreto, sino porque sus implicaciones se extienden por toda la arquitectura de Ethereum de maneras que no serán obvias hasta que las piezas se conecten.
Esto no es Ethereum “agregando ZK” como característica. Ethereum está creando un prototipo de una ruta de validación alternativa en la que algunos validadores pueden dar fe de los bloques verificando pruebas de ejecución compactas en lugar de volver a ejecutar cada transacción.
Si funciona, la función de capa 1 de Ethereum pasa de “liquidación y disponibilidad de datos para acumulaciones” a “ejecución de alto rendimiento cuya verificación sigue siendo lo suficientemente barata para los validadores domésticos”.
¿Qué se está construyendo realmente?
EIP-8025, titulado “Pruebas de ejecución opcionales”, llegó en forma de borrador y especifica la mecánica.
Las pruebas de ejecución se comparten en toda la red peer-to-peer de la capa de consenso a través de un tema dedicado. Los validadores pueden operar en dos modos nuevos: generación de pruebas o validación sin estado.
La propuesta establece explícitamente que “no requiere un hardfork” y sigue siendo compatible con versiones anteriores, mientras que los nodos aún pueden volver a ejecutarse como lo hacen hoy.
El equipo zkEVM de la Fundación Ethereum publicó una hoja de ruta concreta para 2026 el 26 de enero, que describe seis subtemas: testigo de ejecución y estandarización de programas invitados, estandarización de API zkVM-guest, integración de capa de consenso, infraestructura de probador, evaluación comparativa y métricas, y seguridad con verificación formal.
La primera llamada de ruptura L1-zkEVM está programada para el 11 de febrero a las 15:00 UTC.
La canalización de un extremo a otro funciona así: un cliente de capa de ejecución produce un ExecutionWitness, un paquete autónomo que contiene todos los datos necesarios para validar un bloque sin mantener el estado completo.
Un programa de invitados estandarizado consume ese testimonio y valida la transición del estado. Un zkVM ejecuta este programa y un prover genera una prueba de ejecución correcta. Luego, el cliente de la capa de consenso verifica esa prueba en lugar de llamar al cliente de la capa de ejecución para volver a ejecutarla.
La dependencia clave es ePBS (Separación consagrada entre proponentes y constructores), destinada al próximo hardfork de Glamsterdam. Sin ePBS, la ventana de prueba es de aproximadamente uno o dos segundos, lo cual es demasiado ajustado para la prueba en tiempo real. Con ePBS proporcionando canalización de bloques, la ventana se extiende de seis a nueve segundos.
La compensación de la descentralización
Si las pruebas opcionales y los formatos de testigos maduran, más validadores locales pueden participar sin mantener el estado completo de la capa de ejecución.
Aumentar los límites de gas se vuelve política y económicamente más fácil porque el costo de validación se desvincula de la complejidad de la ejecución. El trabajo de verificación ya no escala linealmente con la actividad en la cadena.
Sin embargo, la revisión conlleva su propio riesgo de centralización. Una publicación de Ethereum Research del 2 de febrero informa que probar un bloque Ethereum completo actualmente requiere aproximadamente 12 GPU y toma un promedio de 7 segundos.
El autor señala preocupaciones sobre la centralización y señala que los límites siguen siendo difíciles de predecir. Si las pruebas siguen teniendo mucha GPU y se concentran en redes de constructores o probadores, Ethereum puede cambiar “todos vuelven a ejecutar” por “pocos prueban, muchos verifican”.
El diseño tiene como objetivo abordar esto introduciendo la diversidad de clientes en la capa de prueba. El supuesto de trabajo de EIP-8025 es un umbral de tres de cinco, lo que significa que un certificador acepta la ejecución de un bloque como válida una vez que ha verificado tres de cinco pruebas independientes de diferentes implementaciones de cliente de capa de ejecución.
Esto preserva la diversidad de clientes a nivel de protocolo pero no resuelve el problema de acceso al hardware.
El marco más honesto es que Ethereum está cambiando el campo de batalla de la descentralización. La restricción actual es “¿puede permitirse el lujo de ejecutar un cliente de capa de ejecución?” La pregunta de mañana podría ser “¿puedes acceder a clústeres de GPU o redes de prueba?”
La apuesta es que la verificación de pruebas es más fácil de comercializar que el almacenamiento estatal y la reejecución, pero la cuestión del hardware sigue abierta.
Desbloqueo de escala L1
La hoja de ruta de Ethereum, actualizada por última vez el 5 de febrero, enumera la “apatridia” como un tema de actualización importante: verificar bloques sin almacenar estados grandes.
Las pruebas de ejecución opcionales y los testigos son el mecanismo concreto que hace práctica la validación sin estado. Un nodo sin estado requiere sólo un cliente de consenso y verifica las pruebas durante el procesamiento de la carga útil.
La sincronización se reduce a descargar pruebas de bloques recientes desde el último punto de control de finalización.
Esto es importante para los límites de gas. Hoy en día, cada aumento en el límite de gas dificulta la ejecución de un nodo. Si los validadores pueden verificar las pruebas en lugar de volver a ejecutarlas, el costo de la verificación ya no aumenta con el límite de gas. La complejidad de ejecución y el costo de validación se desacoplan.
El flujo de trabajo de evaluación comparativa y revisión de precios en la hoja de ruta para 2026 apunta explícitamente a métricas que asignan el gas consumido a los ciclos de prueba y al tiempo de prueba.
Si esas métricas se estabilizan, Ethereum obtiene una palanca que no había tenido antes: la capacidad de aumentar el rendimiento sin aumentar proporcionalmente el costo de ejecutar un validador.
Qué significa esto para las cadenas de bloques de capa 2
Una publicación reciente de Vitalik Buterin sostiene que las cadenas de bloques de capa 2 deberían diferenciarse más allá del escalamiento y vincula explícitamente el valor de una “precompilación nativa” con la necesidad de pruebas zkEVM consagradas de que Ethereum ya necesita escalar la capa 1.
La lógica es sencilla: si todos los validadores verifican las pruebas de ejecución, una precompilación EXECUTE también puede utilizar las mismas pruebas para paquetes acumulativos nativos. La infraestructura de prueba de capa 1 se convierte en infraestructura compartida.
Esto cambia la propuesta de valor de la capa 2. Si la capa 1 puede escalar a un alto rendimiento manteniendo bajos los costos de verificación, los paquetes acumulativos no pueden justificarse sobre la base de que “Ethereum no puede manejar la carga”.
Los nuevos ejes de diferenciación son máquinas virtuales especializadas, latencia ultrabaja, confirmaciones previas y modelos de componibilidad como paquetes acumulativos que se apoyan en diseños de prueba rápida.
El escenario en el que las capas 2 siguen siendo relevantes es aquel en el que los roles se dividen entre especialización e interoperabilidad.
La capa 1 se convierte en la capa de ejecución y liquidación de alto rendimiento y bajo costo de verificación. Las capas 2 se convierten en laboratorios de funciones, optimizadores de latencia y puentes de componibilidad.
Sin embargo, eso requiere que los equipos de capa 2 articulen nuevas propuestas de valor y que Ethereum cumpla con la hoja de ruta de verificación de pruebas.
Tres caminos a seguir
Hay tres escenarios potenciales en el futuro.
El primer escenario consiste en que la validación de prueba primero se vuelva común. Si las pruebas opcionales y los formatos de testigos maduran y las implementaciones del cliente se estabilizan en torno a interfaces estandarizadas, más validadores locales podrán participar sin ejecutar el estado de la capa de ejecución completa.
Los límites de gas aumentan porque el costo de validación ya no se alinea con la complejidad de la ejecución. Esta ruta depende de que el flujo de trabajo de estandarización del programa invitado y ExecutionWitness converja en formatos portátiles.
En el escenario dos, la centralización de proveedores se convierte en el nuevo cuello de botella. Si las pruebas siguen teniendo mucha GPU y se concentran en redes de constructores o probadores, entonces Ethereum cambia el campo de batalla de la descentralización del hardware de los validadores a la estructura del mercado de probadores.
El protocolo todavía funciona, ya que un probador honesto en cualquier lugar mantiene viva la cadena, pero el modelo de seguridad cambia.
El tercer escenario es que la verificación de prueba de capa 1 se convierta en una infraestructura compartida. Si la integración de la capa de consenso se fortalece y ePBS ofrece la ventana de prueba extendida, entonces la propuesta de valor de la Capa 2 se inclina hacia máquinas virtuales especializadas, latencia ultrabaja y nuevos modelos de componibilidad en lugar de “escalar Ethereum” solo.
Esta ruta requiere que ePBS se envíe según lo previsto a Glamsterdam.
| Guión | Lo que debe ser cierto (condiciones técnicas previas) | Qué se rompe/principal riesgo | Qué mejora (descentralización, límites de gas, tiempo de sincronización) | Resultado del rol L1 (rendimiento de ejecución versus costo de verificación) | Implicación L2 (nuevo eje de diferenciación) | Señal “Qué mirar” |
|---|---|---|---|---|---|---|
| La validación de prueba primero se vuelve común | Los estándares del programa Testigo de Ejecución + Invitado convergen; zkVM/guest API estandarizada; La ruta de verificación de prueba CL es estable; las pruebas se propagan de forma fiable en P2P; Semántica de umbral de prueba múltiple aceptable (por ejemplo, 3 de 5). | La disponibilidad/latencia de la prueba se convierte en una nueva dependencia; los errores de verificación se vuelven sensibles al consenso si/cuando se confía en él; discrepancia entre clientes/probadores | Validadores de inicio puede dar fe sin estado EL; caídas de tiempo de sincronización (pruebas desde el punto de control de finalización); Los aumentos del límite de gas se vuelven más fáciles porque el costo de verificación se desvincula de la complejidad de la ejecución | L1 se desplaza hacia ejecución de mayor rendimiento con costo de verificación constante para muchos validadores | Los L2 deben justificarse más allá de “L1 no puede escalar”: máquinas virtuales especializadasejecución específica de la aplicación, modelos de tarifas personalizados, privacidad, etc. | Endurecimiento por vector de prueba/especificaciones; portabilidad de testigos/invitados entre clientes; chismes de prueba estable + manejo de fallas; curvas de referencia (gas → ciclos de prueba/tiempo) |
| La centralización del demostrador se convierte en el cuello de botella | La generación de pruebas sigue teniendo mucha GPU; consolidación del mercado de pruebas (constructores / redes de pruebas); pruebas limitadas a “escala de garaje”; La vivacidad se basa en un pequeño conjunto de probadores sofisticados. | “Pocos prueban, muchos verifican” concentra el poder; Se intensifica dinámica censura/MEV; las interrupciones del probador crean tensión de vitalidad/finalidad; riesgo de concentración geográfica / regulatoria | Los validadores aún pueden verificar a bajo costo, pero turnos descentralizados: certificación más fácil, prueba más difícil; cierto margen de maniobra en el límite del gas, pero limitado por la economía probada | L1 se convierte ejecución escalable en teoríapero prácticamente delimitado por Capacidad del probador y estructura del mercado. | Los L2 pueden inclinarse hacia basado / pre-confirmado diseños, sistemas de prueba alternativos o garantías de latencia, lo que potencialmente aumenta la dependencia de actores privilegiados. | Demostrar tendencias de costos (requisitos de hardware, tiempo por bloque); métricas de diversidad de probadores; incentivos para la prueba distribuida; simulacros de modo de falla (¿qué sucede cuando faltan pruebas?) |
| La verificación de prueba L1 se convierte en infraestructura compartida | La integración CL se “endurece”; las pruebas se producen y consumen ampliamente; ePBS se envía y proporciona una ventana de prueba viable; las interfaces permiten la reutilización (por ejemplo, precompilación estilo EXECUTE/enganches acumulativos nativos) | Riesgo de acoplamiento entre dominios: si la infraestructura de prueba L1 está estresada, las rutas de verificación acumuladas también podrían verse afectadas; La complejidad/superficie de ataque se expande. | La infraestructura compartida reduce el esfuerzo de prueba duplicado; mejora la interoperabilidad; costos de verificación más predecibles; camino más claro hacia un mayor rendimiento L1 sin poner precio a los validadores | L1 evoluciona hacia un ejecución con prueba verificada + capa de liquidación eso también puede verificar paquetes acumulativos de forma nativa | Los L2 giran hacia latencia (preconfiguraciones)entornos de ejecución especializados y modelos componibles (por ejemplo, diseños de prueba rápida/sincrónicos) en lugar de “solo escala” | Progreso de ePBS/Glamsterdam; demostraciones de canalización de un extremo a otro (testigo → prueba → verificación CL); puntos de referencia + posible revisión del precio del gas; Implementación de una semántica y monitoreo de distribución de pruebas mínima viable. |
El panorama más amplio
La madurez de la integración de especificaciones de consenso indicará si las “pruebas opcionales” pasan de ser en su mayoría TODO a vectores de prueba reforzados.
La estandarización de ExecutionWitness y el programa invitado es la piedra angular para la portabilidad de la validación sin estado entre clientes. Los puntos de referencia que asignan el gas consumido a los ciclos de prueba y al tiempo de prueba determinarán si es factible cambiar el precio del gas para que sea compatible con ZK.
El progreso de ePBS y Glamsterdam indicará si la ventana de prueba de seis a nueve segundos se convierte en realidad. Los resultados de las llamadas de grupo revelarán si los grupos de trabajo convergen en interfaces y en una semántica de distribución de pruebas mínima viable.
Ethereum no cambiará pronto a la validación basada en pruebas. EIP-8025 establece explícitamente que “todavía no se pueden basar las actualizaciones en él” y el marco opcional es intencional. Como resultado, se trata de una vía comprobable en lugar de una activación inminente.
Sin embargo, el hecho de que la Fundación Ethereum envió una hoja de ruta de implementación para 2026, programó una reunión telefónica con los propietarios del proyecto y redactó un EIP con mecanismos concretos de chismes entre pares significa que este trabajo ha pasado de la plausibilidad de la investigación a un programa de entrega.
La transformación es silenciosa porque no implica cambios dramáticos en la economía simbólica ni en funciones orientadas al usuario. Pero es fundamental porque reescribe la relación entre la complejidad de la ejecución y el costo de validación.
Si Ethereum puede desacoplar los dos, la capa 1 ya no será el cuello de botella que obliga a todo lo interesante a la capa 2.
Y si la verificación de prueba de capa 1 se convierte en una infraestructura compartida, todo el ecosistema de capa 2 debe responder a una pregunta más difícil: ¿qué estás construyendo que la capa 1 no pueda?
