La visión de Ethereum para 2030 traslada el trabajo a las pruebas criptográficas. ¿Quién verifica el resultado?

La visión de Vitalik Buterin del 27 de septiembre describe a Ethereum pasando de un sistema en el que cada verificador repite gran parte del trabajo hacia uno donde los datos pueden ser muestreados y la ejecución puede ser verificada con pruebas compactas. Una parte, PeerDAS, ya se ha implementado. El cambio de ejecución más amplio sigue en desarrollo. Una prueba puede establecer que un cálculo siguió reglas específicas, pero los usuarios aún necesitan datos, una forma de enviar transacciones y un protocolo que decida cuyo resultado se convierte en final.

La pregunta principal tiene dos respuestas. Un probador produce una prueba criptográfica; un verificador, potencialmente cualquier nodo validador que ejecute el software relevante, comprueba esa prueba contra las reglas y las entradas públicas. La hoja de ruta de Ethereum para una zkEVM de capa base dice que la verificación debería ser mucho más barata que reejecutar cada transacción. Pero decidir si una prueba es sólida no resuelve por sí solo si los datos de la transacción están disponibles o si un operador puede retener la transacción de un usuario.

El ensayo del 27 de septiembre de Buterin, "The cryptographic world computer", enmarca el destino como una combinación de una cadena de bloques, privacidad y verificación criptográficas, y componentes descentralizados fuera de la cadena. Contrasta un patrón más antiguo de descargar y reejecutar con un modelo en el que los nodos muestrean datos y verifican pruebas. Describe otros posibles cambios en el consenso y la construcción de bloques. Esta es una visión técnica personal, no una especificación de actualización final ratificada por todos los equipos de clientes de Ethereum.

La distinción entre lo que existe y lo que se visualiza es importante. PeerDAS llegó con Fusaka en diciembre de 2025, según la actualización de prioridades del protocolo de febrero de 2026 de la Fundación Ethereum. La Fundación dice que los validadores ahora muestrean datos de blob en lugar de descargarlos todos. Un cambio en toda la red hacia la verificación de pruebas de ejecución sucintas para bloques de capa base no se describe como ya implementado. Un lector que escuche que Ethereum "verificará pruebas en 2030" debería preguntar qué prueba, qué computación cubre y qué actores pueden probarla de forma independiente.

PeerDAS comprueba el acceso a los datos, no cada cálculo

La pieza ya implementada es PeerDAS, o muestreo de disponibilidad de datos entre pares. Los rollups colocan los datos de las transacciones en el espacio de blobs de Ethereum para que otros participantes puedan recuperar suficiente información para reconstruir el estado y responsabilizar a un operador de las reglas. El antiguo enfoque de hacer que cada nodo descargue cada blob haría que volúmenes de datos mayores fueran costosos para los validadores ordinarios. El muestreo pide a los nodos que comprueben pequeñas piezas contra compromisos criptográficos mientras la red distribuye suficientes piezas codificadas para la reconstrucción.

La explicación de Ethereum dice que los datos de blob extendidos se dividen en 128 columnas. Un nodo regular se une a al menos 8 subredes de columnas elegidas aleatoriamente. Ocho dividido por 128 es un dieciseisavo de los datos extendidos. La codificación añade redundancia, de modo que esa cantidad corresponde a aproximadamente un octavo del volumen de datos original según la descripción de la documentación. Los números se refieren a la carga de trabajo de datos de un nodo predeterminado, no a una afirmación de que un nodo pueda personalmente contener todo el historial de cada rollup a un octavo del costo.

La codificación estilo Reed-Solomon produce piezas de datos redundantes, y los compromisos criptográficos ayudan a un nodo a verificar que una pieza muestreada pertenece a lo que se anunció. El muestreo proporciona una garantía de disponibilidad probabilística entre los nodos participantes. No reemplaza la validación de ejecución. Un lote de transacciones perfectamente disponible puede contener una transición de estado inválida. De manera similar, una prueba válida sobre una transición de estado no es suficiente para permitir que un usuario reconstruya el estado de una cuenta si los datos necesarios para hacerlo se retienen fuera de las garantías de disponibilidad.

La Fundación Ethereum dijo que Fusaka permitió un aumento de ocho veces en la capacidad teórica de blobs. La palabra teórica importa: el rendimiento sostenido real depende de aumentos programados de parámetros, condiciones de la red y uso de rollups. Crypto.news ha explicado cómo los rollups utilizan la capa de datos de Ethereum. El nuevo ensayo de Buterin trata a PeerDAS como el primer paso visible hacia un sistema que verifica más y repite menos; no debería ser reconfigurado como la actualización final de prueba de ejecución.

El probador hace el trabajo pesado; los nodos independientes lo verifican

En un modelo de ejecución basado en pruebas, alguien todavía tiene que ejecutar transacciones y construir evidencia sobre el resultado. Esa parte puede usar hardware y software especializados costosos. Una prueba sucinta permite a un verificador comprobar, a un costo mucho menor, que el cambio de estado declarado sigue el programa y las entradas comprometidas bajo las reglas del protocolo. Una verificación matemática no requiere que el verificador confíe en la empresa probadora simplemente porque generó la prueba.

Hay condiciones adjuntas a esa afirmación. El verificador debe ejecutar un sistema de prueba sólido con la clave de verificación correcta, entradas públicas y reglas de ejecución acordadas. Un circuito defectuoso podría probar perfectamente la afirmación incorrecta. Un error en la implementación de un cliente podría aceptar una prueba que debería rechazar. Una clave de actualización que puede cambiar el código del verificador sin controles robustos podría debilitar la garantía. En un protocolo en vivo, las implementaciones independientes y la revisión importan junto con la generación rápida de pruebas.

La página de hoja de ruta de zkEVM de la capa 1 de Ethereum describe un futuro en el que un nodo verifica una prueba de ejecución de bloque en lugar de repetir cada transacción. Su objetivo declarado es reducir el costo de recursos de la verificación. Eso haría más fácil para más personas verificar bloques si la verificación de pruebas sigue siendo práctica en hardware accesible. No significa que cada hogar pueda producir una prueba de bloque, ni que la producción de pruebas se distribuirá de manera uniforme.

Crypto.news informó sobre una competencia de hardware en torno a la prueba. La distinción útil es entre quién puede generar una prueba a tiempo para la cadena y quién puede verificarla de manera económica. La generación de pruebas podría concentrarse entre empresas con hardware especializado sin permitir automáticamente que esas empresas falsifiquen una transición de estado válida. Aún podría introducir una dependencia de vivacidad: si muy pocas partes pueden producir pruebas lo suficientemente rápido, los bloques o la finalidad podrían ralentizarse incluso cuando el sistema de pruebas siga siendo matemáticamente sólido. Ese es un riesgo diferente al de que se acepte una prueba inválida.

Por lo tanto, la cuestión de la verificación tiene una respuesta humana además de una matemática. Los desarrolladores configuran el circuito, los investigadores lo auditan, los equipos de clientes lo implementan, los operadores de nodos ejecutan verificadores y los participantes deciden si aceptan actualizaciones del protocolo. Buterin puede proponer una dirección. No puede por sí solo hacer que un futuro verificador sea seguro u obligatorio para la red.

Tres promesas a menudo se pliegan en la palabra prueba

Tomemos un usuario que envía un pago a través de un rollup. La transacción tiene que incluirse en un lote ordenado. Los datos del lote deben estar disponibles bajo el modelo elegido por el rollup. Finalmente, el cambio de estado resultante debe seguir sus reglas. El ordenamiento, la disponibilidad y la corrección son promesas separadas. Una prueba de corrección aborda la última para un cálculo especificado. PeerDAS aborda la disponibilidad de los datos de blobs de Ethereum. Un secuenciador o mecanismo de construcción de bloques afecta qué transacciones se incluyen y en qué orden.

Crypto.news examinó los secuenciadores como un punto de control distinto. Una prueba perfectamente válida puede atestiguar que un lote fue procesado de acuerdo con las reglas incluso si su operador excluyó la transacción de un cliente en particular. Un usuario podría tener una ruta de escape o de inclusión forzada dependiendo del diseño de ese rollup, pero la prueba en sí no obliga a un acceso justo. Un secuenciador también puede reordenar transacciones mientras sigue produciendo una transición de estado válida. La declaración que se prueba no debe confundirse con todas las propiedades que los usuarios desean de un mercado.

El lado de los datos es igual de fácil de difuminar. La documentación de validium de Ethereum describe sistemas que utilizan pruebas de validez pero no publican los datos de transacciones en la red principal de Ethereum. Su ejecución puede ser correcta según un verificador, pero un fallo de disponibilidad de datos puede impedir que los usuarios reconstruyan el estado o retiren fondos como esperaban. Un rollup de Ethereum que publica datos suficientes en Ethereum tiene un modelo de disponibilidad diferente. Llamar a ambos simplemente "ZK" oculta una diferencia crítica en la capacidad de un usuario para recuperar el estado de una cuenta sin el operador.

La prueba más simple es una lista de verificación mental de tres columnas. Pregunte quién incluye una transacción en el lote. Pregunte dónde se pueden recuperar los datos necesarios para reconstruir los saldos. Pregunte qué contrato o nodo verifica la prueba de corrección del estado. Si un proyecto responde solo a la tercera, no ha respondido a las dos primeras. Es por eso que el ensayo de Buterin habla sobre la construcción de bloques y la distribución de datos de la red junto con la criptografía, en lugar de reemplazar todo el sistema con una única prueba mágica.

La capa base no puede tomar prestadas todas las propiedades de los rollups existentes

Los rollups ZK ya envían pruebas de validez a Ethereum bajo sus propios contratos y reglas. La documentación de Ethereum sobre rollups ZK describe a un operador creando una prueba para un lote y a un contrato verificador aceptando una nueva raíz de estado solo después de la verificación. Eso es un precedente útil para probar la computación. No significa que la capa base de Ethereum ya haya trasladado toda la validación de ejecución a dichas pruebas.

El alcance difiere. Un rollup prueba su propia transición de estado bajo su propia máquina virtual y contrato, mientras que el verificador de la capa base de Ethereum tendría que comprobar la ejecución de bloques del protocolo de una manera que los equipos de clientes acepten. Una discrepancia entre la lógica personalizada de un rollup y las reglas de ejecución de la red principal de Ethereum no es un detalle que un probador más rápido pueda desear eliminar. Los sistemas de prueba también deben mantenerse robustos a través de actualizaciones del protocolo, nuevos tipos de transacciones y entradas adversarias.

Una aplicación puede externalizar su aritmética a un coprocesador y proporcionar un resultado con una prueba, pero la cadena base sigue decidiendo si acepta las entradas públicas, almacena compromisos y liquida el estado resultante. Una aplicación puede ser capaz de elegir su propio diseño de probador; una regla de la capa base requiere una amplia coordinación entre clientes y validadores. La frase de Buterin "computadora mundial criptográfica" es útil como dirección arquitectónica, no como una promesa de que un único servicio de prueba ejecutará todo Ethereum.

Hay una contradicción aparente que vale la pena resolver. Si los nodos dejan de re-ejecutar, ¿cómo encuentra alguien un error en la computación que se está probando? Una respuesta es que los desarrolladores pueden ejecutar una ejecución completa independiente y compararla con los resultados de la prueba durante el desarrollo y después del despliegue. Otra son múltiples implementaciones de prueba y verificaciones formales de circuitos. El diseño exacto de Ethereum no se ha finalizado. Un protocolo que reduce la re-ejecución requerida no prohíbe que las personas realicen comprobaciones adicionales; cambia lo que cada nodo validador ordinario debe hacer para el consenso.

La actualización de prioridades del protocolo de septiembre de la Fundación trata una zkEVM de L1 y la verificación formal como líneas de trabajo principales. Eso es evidencia de ingeniería activa, no una fecha de lanzamiento establecida. El estándar de seguridad es alto porque un error en un sistema de prueba de la capa base afectaría la base sobre la que dependen otras aplicaciones.

Las pruebas pueden mejorar la verificación mientras el problema del estado crece

Buterin nombra el acceso a un estado compartido muy grande como un problema particularmente difícil no resuelto. Crypto.news examinó su propuesta separada para el escalado del mempool basado en pruebas, que apunta a un cuello de botella diferente al de la ejecución final del estado. Una prueba puede atestiguar una computación, pero el probador debe obtener la información de la que depende esa computación: saldos, almacenamiento de contratos y otro estado de cuentas. Si muchas transacciones tocan el mismo estado a la vez, dividir la computación entre máquinas se vuelve más difícil. Un pago desde una cuenta y un swap que toca un pool de liquidez no pueden finalizarse ambos a partir de instantáneas inconsistentes.

El ensayo sugiere que las aplicaciones pueden colocar el ordenamiento y los cambios de estado no conmutativos en la cadena mientras agregan otros cómputos antes de la inclusión. Eso es un incentivo arquitectónico, no una regla vinculante para los desarrolladores de hoy. "No conmutativo" significa que cambiar el orden cambia el resultado. Dos personas que compran del mismo pool reducido pueden obtener precios diferentes según cuál orden se procese primero. Ninguna prueba hace que esos dos órdenes sean económicamente equivalentes.

Esto es un contrapeso útil a una promesa simplista de escala gratuita. El trabajo en paralelo es más fácil cuando las tareas pueden separarse de forma segura. El estado compartido crea dependencias. Un probador puede ejecutar muchos cómputos independientes rápidamente y aun así esperar por el acceso a un estado disputado o por la elección de ordenamiento de un constructor de bloques. Mejorar solo la velocidad de prueba no resuelve la contención de la base de datos, la censura ni el costo de hacer que suficiente información esté disponible para otros participantes.

En la opinión de Buterin, una capa intermedia descentralizada más fuerte podría procesar trabajo en paralelo y, en algunos casos, proteger metadatos sobre el origen de las solicitudes. Dicha infraestructura podría mejorar el rendimiento o la privacidad, pero tendría que especificar cómo se distribuyen los datos, quién puede unirse y qué fallos tienen una vía de escape. La privacidad del pago de un usuario no es una consecuencia automática de usar una prueba de validez. Las entradas públicas, la actividad de la billetera y los metadatos de la red aún pueden revelar información a menos que un sistema también proteja esas partes.

La independencia puede medirse antes de la bifurcación final

"Cualquiera puede verificar" tiene condiciones prácticas. Un nodo ordinario necesita el código del verificador, las entradas públicas relevantes, una conexión al estado aceptado de la cadena y suficiente capacidad de procesamiento para completar la verificación dentro de los límites de tiempo del protocolo. Si una prueba tarda segundos en verificarse en una máquina modesta pero horas en producirse en hardware costoso, el sistema puede lograr una verificación amplia con una producción reducida. Eso puede ser un compromiso de ingeniería aceptable para la corrección, siempre que la interrupción de un productor no se convierta en un bloqueo permanente para la liquidación.

El experimento es sencillo en líneas generales. Ejecutar software verificador de más de un equipo de clientes contra la misma prueba de bloque válida y confirmar que la aceptan. Proporcionar entradas públicas alteradas y confirmar el rechazo. Preguntar si equipos de prueba separados pueden producir pruebas aceptadas para las mismas reglas, con qué rapidez pueden hacerlo y qué hardware requiere cada uno. Repetir esto en una red de prueba pública bajo carga pesada diría más sobre la preparación que una demostración de laboratorio de una prueba rápida. Los criterios exactos de aceptación de Ethereum siguen sujetos al trabajo del protocolo; estas son preguntas observables, no umbrales oficiales de aprobación.

La generación de pruebas tiene otro modo de fallo que una verificación de validez no puede detectar por sí sola. Un probador podría negarse a hacer una prueba para un bloque propuesto. Un verificador no puede aceptar una prueba que no ha llegado. Un diseño puede abordar eso permitiendo múltiples probadores independientes, una vía de ejecución de respaldo, tiempos ajustados u otros mecanismos. La elección afectará la complejidad, el costo y el tiempo hasta la finalidad. Las reglas actuales de la capa base de Ethereum no deberían describirse como si hubieran seleccionado una de esas soluciones futuras meramente porque una hoja de ruta dice que la verificación de pruebas es un objetivo.

La independencia también significa que un usuario puede obtener la información necesaria para verificar su propia reclamación sobre activos. Una prueba de que una raíz de estado siguió el código es poderosa, pero un usuario que no puede reconstruir la ruta desde los datos de su cuenta hasta esa raíz todavía depende de un intermediario para una verificación práctica del saldo. PeerDAS hace que la disponibilidad de datos blob sea menos exigente para cada nodo mientras depende de la distribución y el muestreo en toda la red. Los datos de aplicación guardados en otro lugar necesitan sus propias garantías de disponibilidad. El verificador de pruebas de la cadena no puede obligar a un operador externo a publicar registros retenidos.

Finalmente, el programa que se está verificando debe ser el programa que los usuarios creen que es. Un hash público del código del verificador, un proceso de actualización documentado y pruebas independientes del comportamiento del circuito permiten a los externos comparar la regla anunciada con lo que los nodos realmente aplican. La verificación formal puede reducir la probabilidad de un error lógico, pero también comienza con una especificación escrita por humanos. El resultado verificable no es "la criptografía resolvió la confianza". Es que una afirmación especificada puede rechazarse de forma independiente cuando su evidencia es inválida, sin que cada nodo pague el costo total de producirla.

Hegota es un marcador, no una garantía de lanzamiento para 2030

Buterin se refiere a Hegota, una bifurcación planificada para 2027, como posiblemente la última actualización cuyos componentes serían familiares para un observador de Ethereum de 2015. El trabajo posterior en su relato implicaría STARKs recursivos, verificación formal, consenso optimizado y seguridad cuántica. Crypto.news informó sobre el objetivo cuántico separado para 2029 como una meta de planificación. Ni el ensayo ni una fecha objetivo prueban que cada componente propuesto estará listo y se adoptará según lo previsto.

Las actualizaciones de Ethereum requieren especificaciones, implementaciones de clientes, redes de prueba, revisiones de seguridad y coordinación entre los participantes. Un strawmap es un mapa de investigación e hitos candidatos, no una promulgación en cadena. Uno puede verificar que PeerDAS está desplegado mirando la versión Fusaka y las reglas actuales de los nodos. Uno no puede verificar un futuro zkEVM general de capa base mirando la columna azul de 2030 de un ensayo. La evidencia llegará primero en especificaciones y pruebas públicas, luego un plan de bifurcación concreto y una activación en producción.

El argumento a favor del enfoque de Buterin es sólido. Si la verificación se vuelve barata y los datos pueden muestrearse de forma segura, más usuarios pueden verificar independientemente un sistema más grande sin comprar máquinas proporcionales a toda su computación y datos. El desafío es igual de real: la pila de pruebas debe ser segura, producida de manera competitiva y lo suficientemente rápida para mantener el sistema en vivo, mientras que los datos y el ordenamiento permanecen accesibles. Una red con verificación barata pero un único probador o secuenciador indispensable aún puede ser frágil.

El ensayo no resuelve quién construirá cada prueba o qué sistema de pruebas ganará. Sí identifica una prueba que importa para los usuarios: ¿puede un participante independiente ordinario rechazar un resultado incorrecto, recuperar los datos necesarios para conocer su propio estado y enviar una transacción a pesar de cualquier operador único? Cada respuesta requiere un mecanismo separado. La verificación criptográfica es poderosa precisamente porque puede ser repetida por personas que no hicieron el trabajo pesado.

Qué observar

• Especificaciones del zkEVM de L1. Busque un verificador concreto, un formato de entrada pública y reglas de ejecución aceptadas entre clientes.
• Diversidad de provers. Múltiples implementaciones independientes y necesidades de hardware medidas pondrán a prueba si la producción de pruebas tiene un único punto de estrangulamiento.
• Mediciones de PeerDAS. Compruebe el rendimiento de blobs y el ancho de banda de los nodos a medida que aumentan los parámetros tras el lanzamiento de diciembre de 2025.
• Decisiones sobre Hegota. Un alcance final del fork importa más que las características candidatas en un borrador de hoja de ruta.
• Salvaguardas de datos y ordenamiento. Inspeccione si los rollups y los futuros diseños de la capa base preservan la reconstrucción independiente y la inclusión de transacciones.

Preguntas frecuentes