Por Canuto  

La Ethereum Foundation abrió evm.fast, un desafío para probar cuánta computación puede requerir la verificación de un bloque. El punto de partida es un límite infinito; una prueba finita y verificada por máquina lo superaría y podría dar a los sistemas de pruebas zk una base más confiable para planificar sus costos.
***

  • El desafío busca establecer un límite superior certificado de pasos de ejecución para verificar bloques de Ethereum en un modelo RISC-V de 64 bits.
  • La implementación base demuestra que la verificación termina, pero no establece un techo uniforme para todas las entradas; por eso su puntuación actual es infinito.
  • La Fundación relaciona el trabajo con costos de prueba más previsibles y con la mitigación del riesgo de bloques que exijan más computación de la esperada.

La Ethereum Foundation abrió el desafío evm.fast para encontrar un límite verificable al trabajo computacional que puede exigir la validación de un bloque. La puntuación de partida es infinito: cualquier cota finita respaldada por una prueba comprobada por máquina superaría ese resultado inicial.

Ethereum busca fijar un límite verificable para procesar sus bloques

El reto propone abordar una pregunta clave para la infraestructura de Ethereum: cuál es la mayor cantidad de pasos de ejecución que podría necesitar un programa para verificar un bloque. La Fundación no plantea medir solo el rendimiento promedio, sino obtener una cota de peor caso que sea válida para todas las entradas cubiertas por el desafío y que otros sistemas puedan comprobar formalmente.

La convocatoria se presentó en evm.fast y, según la información publicada por Crypto Briefing el 2 de noviembre de 2026, no incluye premios monetarios, fecha límite ni una plataforma de envío anunciada. Su marcador inicial figura como infinito, no porque se haya determinado que la verificación de un bloque consuma recursos ilimitados, sino porque la implementación de referencia todavía no demuestra un techo uniforme.

Qué intenta medir el desafío evm.fast

La métrica central se denomina K y representa un límite superior certificado de pasos de ejecución para un modelo RISC-V de 64 bits. En términos sencillos, los participantes deben justificar un número que garantice que el programa no superará esa cantidad de pasos al procesar cualquiera de las entradas contempladas por el desafío.

La exigencia no equivale a cronometrar una serie de bloques y reportar el resultado más alto observado. Una medición empírica describe lo que ocurrió en un conjunto de pruebas, mientras que una cota demostrada busca ofrecer una garantía formal para todo el conjunto de casos especificado; esa diferencia importa cuando el objetivo es planificar el máximo costo posible, no el habitual.

El recuento incluye también los pasos de inicio de la ejecución, por lo que no se permite descontar ese trabajo mediante una convención que lo deje fuera del total. La regla hace que K refleje el proceso desde su arranque y evita que una prueba presente como más barato un cálculo que simplemente haya omitido parte del trabajo inicial.

El estado de infinito funciona, entonces, como una línea de base técnica y no como una predicción de que algún bloque real vaya a consumir recursos sin límite. El primer resultado finito que venga acompañado de una prueba verificada por máquina mejoraría el marcador; después, el desafío consistiría en reducir K hasta una cifra suficientemente ajustada para orientar presupuestos de cómputo.

Lean 4, Flapjack y la implementación de referencia

El modelo de ejecución se apoya en Flapjack, un port experimental a Lean del compilador Pancake, originalmente desarrollado en HOL4. Flapjack compila un fragmento del lenguaje Pancake a RISC-V; en este reto, el modelo emplea una arquitectura RISC-V de 64 bits. RISC-V define un conjunto abierto de instrucciones, es decir, el repertorio básico de operaciones que un procesador puede ejecutar.

Lean 4 es un asistente de pruebas que permite revisar formalmente demostraciones matemáticas. En este contexto, su papel es importante porque la respuesta no se limita a afirmar que un límite parece razonable: la prueba debe expresarse de una manera que el sistema pueda comprobar paso a paso, reduciendo la dependencia de una evaluación informal del resultado.

La implementación base, compilada mediante el verificador de compilación Flapjack, ya prueba que la verificación de bloques termina. Sin embargo, demostrar que un programa acaba en cada ejecución no establece por sí solo cuánto puede tardar en el peor caso, ni proporciona un único límite superior que se mantenga para todas las entradas relevantes.

Ese vacío explica la puntuación actual de infinito: existe una demostración de terminación, pero todavía no una cota uniforme finita para el número de pasos. El desafío busca cerrar precisamente esa brecha entre saber que el programa termina y poder poner un techo comprobable al trabajo que realiza durante su ejecución.

Por qué interesa a las pruebas de conocimiento cero

La iniciativa se relaciona con el trabajo de la Fundación en pruebas de conocimiento cero, una técnica que permite demostrar que una computación se ejecutó correctamente sin obligar al verificador a repetirla por completo. Los sistemas capaces de generar pruebas para programas generales suelen conocerse como máquinas virtuales de conocimiento cero, o zkVM, y muchos compilan sus programas a RISC-V.

Para quienes generan pruebas de bloques completos de Ethereum, el costo computacional no es un detalle aislado: condiciona cuánto trabajo puede procesarse dentro de un presupuesto determinado. Una cota de peor caso ayuda a responder qué recursos conviene reservar incluso cuando una entrada resulta mucho más exigente que el bloque típico.

La Fundación ha señalado entre sus objetivos para 2025 y 2026 la seguridad demostrable, la solidez de la recursividad y unos costos de prueba predecibles. La recursividad se refiere a pruebas que verifican otras pruebas; su corrección debe mantenerse a medida que esas pruebas se encadenan, mientras que la previsibilidad de costos busca hacer más calculable el esfuerzo de generar las demostraciones.

El desafío encaja de manera directa con esa última prioridad, aunque una cota por sí sola no hace que una prueba se genere más rápido ni garantiza todos los aspectos de seguridad de una zkVM. Su aporte sería más acotado y concreto: convertir una parte del presupuesto computacional, hoy sin techo uniforme demostrado, en una cantidad respaldada por una prueba formal.

Rendimiento, riesgo y próximos pasos

La información del desafío también destaca avances en la latencia de las pruebas en tiempo real de bloques completos de Ethereum: el tiempo habría bajado desde aproximadamente 16 minutos hasta menos de 10 segundos para el 99% de los bloques de la red principal, en el hardware objetivo. Esa cifra se refiere a los casos señalados y no debe confundirse con una garantía de que todos los bloques puedan probarse en menos de 10 segundos.

El salto de rendimiento descrito convive con una pregunta distinta: cómo planificar para el bloque más costoso, en vez de basar los recursos únicamente en los resultados frecuentes. Si el sistema puede estimar con rigor el peor caso, los equipos que generan pruebas cuentan con una base matemática más firme para organizar su capacidad y valorar si pueden mantenerse al día.

También hay una dimensión de seguridad operativa vinculada con la denegación de servicio. Si un atacante pudiera diseñar un bloque que requiriera muchos más pasos de verificación de los esperados, los generadores de pruebas podrían quedar rezagados; una cota certificada no elimina por sí sola todo riesgo, pero reduce el espacio para sorpresas computacionales de ese tipo.

Además de este reto, la Fundación mantiene trabajo relacionado con la estimación de seguridad, la verificación de programas invitados y la semántica de RISC-V en la ejecución de Ethereum. Un programa invitado es el código que ejecuta y prueba una zkVM; aquí corresponde a la lógica que comprueba un bloque, por lo que su análisis se conecta directamente con la búsqueda de una cota útil.

Por ahora, no se han comunicado recompensas, plazos ni mecanismos de participación, de modo que el anuncio define el problema técnico, pero deja esos detalles abiertos. La primera meta será reemplazar el infinito por cualquier límite finito que supere la verificación formal; el desafío de fondo será estrechar después K hasta un valor que sirva para planificar, sin confundir una garantía matemática con una promesa de rendimiento idéntico en todos los equipos.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados