Ethereum planea un cambio en la forma en que se puede verificar la validez de los bloques en la capa base. Bajo la hoja de ruta L1-zkEVM para 2026, la validación puede pasar de reejecutar cada transacción a verificar pruebas de conocimiento cero. Este método permite que un attestador confirme la ejecución correcta verificando pruebas criptográficas en lugar de reproducir toda la computación. EIP-8025, conocido como Pruebas de Ejecución Opcionales, respalda este enfoque. Los nodos aún pueden validar bloques mediante reejecución completa usando un cliente de ejecución. Sin embargo, un camino basado en pruebas puede ejecutarse en paralelo, permitiendo que los attestadores verifiquen las pruebas de ejecución y continúen sin realizar un flujo de trabajo de ejecución completo.
https://t.co/TwylcccdzB
— ladislaus.eth (@ladislaus0x) 9 de febrero de 2026
Una canalización de pruebas es fundamental para este diseño. Un cliente de capa de ejecución genera un “Testigo de Ejecución” para cada bloque. Ese testigo empaqueta los datos necesarios para validar la transición de estado sin que un verificador tenga que poseer el estado completo de la ejecución. Luego, un programa huésped estandarizado consume el testigo y verifica las reglas de transición. Después, un zkVM ejecuta el programa huésped y un probador genera una prueba. Finalmente, un cliente de capa de consenso puede verificar la prueba durante el procesamiento del bloque. En medio de la reciente actualización de Ethereum, CNF también señaló que los desarrolladores planean comenzar a trabajar en la actualización Hegota más adelante en 2026, después de completar Glamsterdam en la primera mitad del año. Las discusiones sobre Hegota incluyen FOCIL, un diseño de lista de inclusión de elección de bifurcación que busca acabar con la censura de transacciones por parte de los constructores de bloques. EIP-8025 de Ethereum añade Gossip de Pruebas y una opción zkAttester EIP-8025 establece la mecánica a nivel de consenso para manejar pruebas de ejecución. Las pruebas de diferentes implementaciones de clientes de ejecución pueden propagarse a través de un tema de gossip dedicado en la red p2p. Como resultado, los attestadores pueden obtener las pruebas y verificarlas mientras procesan los bloques, en lugar de llamar a un cliente de ejecución para volver a ejecutar las transacciones. Un modelo de múltiples pruebas forma parte del plan actual. Bajo esta configuración, un attestador puede aceptar la ejecución una vez que verifique un umbral de pruebas independientes para el mismo bloque. Un parámetro de trabajo de referencia es un umbral de 3 de 5, lo que significa que tres pruebas verificadas de cinco pueden satisfacer la verificación. Sin embargo, el umbral se trata como ajustable a medida que continúan las pruebas y revisiones de seguridad. El tiempo de las pruebas también está ligado al trabajo de separación entre proponente y constructor. La separación enraizada entre proponente y constructor, o ePBS, puede extender la ventana de prueba permitiendo la canalización de bloques a través de un intervalo. Con más tiempo disponible, la generación de pruebas se vuelve más factible dentro del tiempo normal de consenso. Un taller de L1-zkEVM está programado para el 11 de febrero de 2026 a las 15:00 UTC. La agenda de la sesión cubre seis líneas de trabajo. Estas incluyen la estandarización de testigos de ejecución y programas huéspedes, trabajo en la interfaz zkVM-huésped, integración en la capa de consenso, infraestructura de probadores, evaluación comparativa y métricas, además de trabajo de seguridad que incluye verificación formal. A principios de este mes, CNF señaló que Payy Link lanzó Payy Network, que afirma ser la primera y única capa 2 de EVM habilitada para privacidad en Ethereum. Las transferencias ERC 20 son privadas por defecto, no requieren cambios en contratos inteligentes y soportan billeteras EVM de forma nativa.
Artículos relacionados
ETH sube 0.80% en 15 minutos: La afluencia de fondos en cadena y el sentimiento alcista en derivados impulsan el movimiento