Ethereum se está preparando para validar bloques sin ejecutarlos – Aquí te explicamos cómo

Un cambio sutil pero consecuente está tomando forma dentro de la arquitectura central de Ethereum. En lugar de validar bloques volviendo a ejecutar cada transacción, la red está preparando una vía alternativa donde los validadores confirman la corrección mediante la Verificación de Prueba de conocimiento cero.

El trabajo se encuentra dentro de la hoja de ruta de la Capa 1 de Ethereum para 2026 y representa un cambio estructural en cómo se puede alcanzar el consenso, no una nueva función de escalado añadida en los bordes.

La propuesta surgió públicamente después de que un miembro de la Ethereum Foundation, conocido como ladislaus.eth, describiera el progreso hacia un diseño L1-zkEVM. El cambio no altera cómo se producen los bloques o qué envían los usuarios en la cadena. En cambio, cambia cómo los validadores deciden si un bloque es válido. El primer taller L1-zkEVM está programado para el 11 de febrero de 2026, marcando el inicio formal de la coordinación en torno a este esfuerzo.

De la Re-Ejecución Completa a la Verificación de Prueba

Hoy en día, cualquier validador que quiera dar fe de un bloque debe volver a ejecutar cada transacción dentro de él. Cada nodo repite independientemente el mismo cálculo, verifica las mismas transiciones de estado y almacena el mismo estado de ejecución. Este modelo se ha mantenido desde el génesis de Ethereum, pero escala linealmente con la actividad. Los límites de gas más altos aumentan la carga computacional, el tamaño del estado y los requisitos de ancho de banda para cada participante.

La alternativa que se está desarrollando reemplaza el cálculo repetido con Verificación criptográfica. En lugar de volver a ejecutar transacciones, un validador verifica una Prueba de conocimiento cero compacta que muestra que la ejecución se realizó correctamente. El tiempo de Verificación permanece aproximadamente constante independientemente de cuán complejo fue el bloque internamente. Esta es la idea central detrás de las pruebas zkEVM, que ahora se están diseñando directamente en el flujo de trabajo de consenso de Ethereum.

Cómo Funciona el Pipeline L1-zkEVM

Bajo el diseño actual, un cliente de ejecución produce un Testigo de Ejecución, un paquete autónomo de datos suficiente para validar la transición de estado de un bloque sin mantener el estado de ejecución completo. Un programa invitado estandarizado consume ese testigo y verifica la corrección de la ejecución. Un zkVM ejecuta este programa y genera una prueba que atestigua que la ejecución siguió las reglas de Ethereum.

Los clientes de consenso pueden entonces verificar esa prueba en lugar de invocar un cliente de ejecución completo. Los validadores que eligen esta ruta se denominan zkAttesters. Importante, esta vía es opcional. Los validadores pueden continuar re-ejecutando bloques exactamente como lo hacen hoy.

Este mecanismo está formalizado bajo EIP-8025 (Pruebas de Ejecución Opcionales). La propuesta no requiere un hard fork y no obliga a los validadores a adoptar la validación basada en pruebas. Añade una vía de Verificación paralela junto a la re-ejecución.

Integración de Consenso y Diversidad de Clientes

EIP-8025 especifica cómo circularían las pruebas a través de la red peer-to-peer. Las pruebas de ejecución de diferentes implementaciones de clientes se difunden en un tema dedicado. Al procesar un bloque, un zkAttester puede verificar estas pruebas en lugar de llamar a un cliente de ejecución.

La suposición de trabajo actual es un umbral de 3 de 5. La ejecución de un bloque se acepta una vez que tres de cinco pruebas independientes se verifican con éxito. Este umbral puede evolucionar, pero la intención es clara: preservar la diversidad de clientes de ejecución mientras se permite la validación basada en pruebas. La diversidad sigue siendo una característica a nivel de protocolo en lugar de una elección operativa.

Por Qué Esto Importa para los Validadores

Un zkAttester no necesita almacenar el estado de ejecución ni sincronizar la cadena completa de la capa de ejecución. La sincronización se reduce a descargar pruebas recientes desde el último punto de control finalizado. Esto reduce drásticamente los requisitos de hardware para participar en el consenso.

Para los stakers en solitario y validadores domésticos, esto es material. Ejecutar un validador hoy requiere mantener tanto un cliente de consenso como un cliente de ejecución que consume muchos recursos. La Verificación de prueba reemplaza la re-ejecución, reduciendo las demandas de almacenamiento, cálculo y ancho de banda. Esto reduce la barrera de entrada sin debilitar las garantías de Verificación.

Las implicaciones se extienden más allá de los attesters. Debido a que las pruebas zkEVM son sin estado, verificar Ethereum localmente en hardware de consumo se vuelve más accesible nuevamente. El principio "no confíes, verifica" se fortalece en lugar de diluirse.

Dependencias y Restricciones de Tiempo

Un prerrequisito importa. La generación de pruebas requiere tiempo, y sin canalización, la ventana es demasiado ajustada. Aquí es donde ePBS (Separación Consagrada Propuesto-Constructor) se vuelve relevante. Dirigido al próximo hard fork de Glamsterdam, ePBS extiende la ventana de prueba de aproximadamente uno a dos segundos a alrededor de seis a nueve segundos. Esa extensión hace que la generación de pruebas de un solo slot sea mucho más realista.

Sin ePBS, la Verificación de prueba L1 permanece limitada. Con ella, el diseño se vuelve operacionalmente viable.

XRP Whale Selling Remains Absent as Price Slides

Quién Se Ve Afectado

Los equipos de clientes de la capa de ejecución obtienen una nueva superficie de prueba, con cada cliente convirtiéndose en una fuente potencial de prueba. El diseño del probador sigue siendo una cuestión abierta. Concentrar la prueba en un pequeño conjunto de constructores sofisticados introduce riesgos de vivacidad, mientras que la prueba completamente distribuida plantea desafíos de rendimiento y coordinación. El objetivo de diseño es explícito: la prueba debe permanecer viable fuera de los grandes centros de datos.

Los proveedores de zkVM que ya prueban bloques de Ethereum obtienen una interfaz estandarizada contra la cual construir. Los equipos de Capa 2 también se benefician. Una vez que las pruebas de ejecución son verificadas por los validadores, las mismas pruebas pueden servir a rollups nativos a través de infraestructura compartida.

En última instancia, los usuarios se benefician de una Verificación más barata, una participación más amplia de validadores y límites de gas factibles más altos sin presión de centralización.

Estado Actual

EIP-8025 ha entrado en la rama de características de consensus-specs y está progresando hacia el estado de propuesta. La hoja de ruta L1-zkEVM para 2026 ya es pública, estructurada en estandarización de testigos de ejecución, interfaces zkVM, integración de consenso, infraestructura de probador, benchmarking y Verificación de seguridad formal.

El taller del 11 de febrero de 2026 marca el comienzo de la coordinación enfocada en estas pistas. Esta no es una actualización que acapare titulares, pero es fundamental. Si Ethereum escala su capa de ejecución sin escalar los requisitos del validador, así es como sucede.

La publicación Ethereum Se Está Preparando para Validar Bloques Sin Ejecutarlos – Así Es Como apareció primero en ETHNews.