La visión de Ethereum para 2030 depende de las pruebas. Lo difícil es quién las verifica

La última hoja de ruta de Ethereum de Vitalik Buterin apunta hacia un tipo de red diferente.

En «La computadora mundial criptográfica», publicado el 27 de septiembre, Buterin describe a Ethereum alejándose de un modelo en el que cada verificador repite gran parte del mismo trabajo. La versión futura depende más del muestreo de datos, de pruebas criptográficas compactas y de componentes fuera de la cadena que pueden realizar cálculos sin obligar a cada nodo ordinario a reproducirlos.

Una parte de esa visión ya ha llegado. PeerDAS se puso en marcha con la actualización Fusaka de Ethereum en diciembre de 2025. Permite a los validadores muestrear datos de blobs en lugar de descargarlos todos.

El cambio más amplio, usar pruebas para verificar la ejecución de la capa base de forma más general, sigue siendo trabajo futuro.

Esa distinción importa. Una prueba puede demostrar que un cálculo siguió reglas especificadas. No garantiza automáticamente que los datos de las transacciones estén disponibles, que los usuarios puedan entrar en un lote o que ningún operador pueda censurar o reordenar la actividad.

La cuestión no es solo si Ethereum puede generar pruebas. Es si los participantes ordinarios pueden verificar los resultados de forma independiente.

Lo que ya existe

La parte desplegada es PeerDAS, abreviatura de muestreo de disponibilidad de datos entre pares.

Los rollups usan el espacio de blobs de Ethereum para publicar datos de transacciones de modo que otros participantes puedan reconstruir el estado y cuestionar o verificar el comportamiento del rollup. El modelo antiguo, en el que cada nodo descarga cada blob, hace que un mayor rendimiento de datos sea caro para los validadores.

PeerDAS cambia eso al permitir que los nodos muestreen piezas más pequeñas de datos contra compromisos criptográficos. La documentación de Ethereum dice que los datos de blobs extendidos se dividen en 128 columnas. Un nodo regular se suscribe a al menos ocho subredes de columnas seleccionadas aleatoriamente.

Eso significa que un nodo por defecto verifica una decimosexta parte de los datos extendidos. Como la codificación añade redundancia, la documentación de Ethereum describe esa carga de trabajo como aproximadamente una octava parte del volumen de datos original.

Esto no significa que un nodo almacene o verifique personalmente todo el historial del rollup a una octava parte del coste. Significa que la red distribuye y muestrea suficientes datos codificados para crear una garantía probabilística de disponibilidad.

PeerDAS comprueba la disponibilidad de datos. No valida cada cálculo.

Un lote de transacciones puede estar disponible y aun así contener una transición de estado inválida. Una prueba puede demostrar que una transición de estado fue válida, pero si los datos necesarios para reconstruir los saldos de las cuentas no están disponibles, los usuarios pueden seguir dependiendo de un operador.

Las pruebas trasladan el trabajo pesado a otra parte

En un modelo de ejecución basado en pruebas, alguien todavía tiene que ejecutar transacciones.

Esa parte puede usar hardware caro y software especializado para producir una prueba criptográfica que demuestre que el cambio de estado declarado sigue las reglas acordadas. Un verificador puede entonces comprobar la prueba mucho más barato que reejecutando cada transacción.

Esa es la promesa central de un zkEVM de L1: reducir el coste de comprobar los bloques de Ethereum sin exigir que cada nodo validador rehaga toda la ejecución.

Pero deben cumplirse varias condiciones.

El verificador debe usar el sistema de prueba correcto, la clave de verificación, las entradas públicas y las reglas de ejecución. Un circuito defectuoso puede probar la afirmación equivocada. Un error del cliente puede aceptar una prueba que debería rechazar. Un mecanismo de actualización que pueda cambiar el código del verificador sin controles fuertes puede debilitar la garantía.

La generación rápida de pruebas no es lo mismo que una verificación segura. Ethereum seguirá necesitando implementaciones independientes, auditorías, revisión formal y diversidad de clientes.

La capa humana sigue siendo parte del sistema. Los desarrolladores definen el circuito. Los investigadores lo examinan. Los equipos de clientes lo implementan. Los operadores de nodos ejecutan verificadores. La comunidad decide si acepta las actualizaciones del protocolo.

Buterin puede proponer la dirección. No puede, por sí solo, hacer que un verificador futuro sea seguro u obligatorio.

La verificación y la producción de pruebas son mercados diferentes

Un futuro sistema de pruebas de Ethereum podría hacer que la verificación sea ampliamente accesible mientras deja la producción de pruebas concentrada.

Eso no es necesariamente fatal. Una prueba puede tardar horas o requerir hardware caro para producirse, pero solo segundos para verificarse en máquinas ordinarias. Si muchos nodos pueden rechazar pruebas inválidas de forma barata, la corrección puede seguir siendo ampliamente comprobable incluso si la generación de pruebas está especializada.

El riesgo es la vivacidad.

Si solo unas pocas partes pueden producir pruebas lo suficientemente rápido para la cadena, la red puede volverse dependiente de esas partes. Puede que no puedan falsificar una transición de estado válida, pero su fallo o negativa a producir pruebas podría ralentizar el procesamiento de bloques o la finalidad.

Ese es un riesgo diferente de aceptar una prueba inválida. Sigue siendo real.

Un diseño robusto necesitaría múltiples probadores independientes, mecanismos de respaldo, reglas de temporización u otras formas de mantener la cadena viva cuando falle un sistema de pruebas.

Ethereum no ha finalizado ese diseño.

Las pruebas no resuelven todos los problemas

La palabra «prueba» a menudo comprime tres garantías separadas en una.

Un usuario que envía una transacción a través de un rollup necesita tres cosas.

Primero, la transacción debe incluirse en un lote ordenado. Segundo, los datos necesarios para reconstruir el estado deben estar disponibles. Tercero, la transición de estado debe seguir las reglas.

Una prueba de validez aborda el tercer punto. PeerDAS aborda la disponibilidad de los datos de blobs de Ethereum. Los secuenciadores, los constructores de bloques y los mecanismos de inclusión afectan al primer punto.

Son problemas diferentes.

Un operador de rollup puede producir una prueba válida para un lote que excluye la transacción de un usuario concreto. Un secuenciador puede reordenar transacciones y aun así generar una transición de estado válida. Que un usuario tenga una vía de inclusión forzada depende del diseño del rollup, no de la existencia de una prueba por sí sola.

La misma distinción se aplica a los datos.

La documentación de Ethereum describe los validiums como sistemas que usan pruebas de validez pero no publican datos de transacciones en la red principal de Ethereum. Su ejecución puede ser válida, mientras que los usuarios pueden tener dificultades para reconstruir el estado o retirar fondos si falla la disponibilidad de datos fuera de la cadena.

Un rollup que publica datos suficientes en Ethereum tiene un modelo de confianza diferente.

Llamar «ZK» a ambos sistemas puede ocultar la diferencia más importante: si los usuarios pueden recuperar el estado de su cuenta sin depender del operador.

La capa base no es solo otro rollup

Los rollups ZK ya envían pruebas de validez a Ethereum. Sus operadores generan pruebas para lotes, y los contratos verificadores aceptan nuevas raíces de estado solo después de comprobar esas pruebas.

Ese es un precedente útil. No significa que la capa base de Ethereum ya haya trasladado la validación de la ejecución a las pruebas.

El alcance es diferente.

Un rollup prueba su propia transición de estado bajo su propia máquina virtual y contratos. La capa base de Ethereum necesitaría verificar la ejecución de bloques a nivel de protocolo de una forma que todos los equipos de clientes acepten.

El verificador de la capa base debe manejar las reglas de ejecución de Ethereum, las actualizaciones del protocolo, los tipos de transacciones y las entradas adversarias. No puede simplemente tomar prestadas las suposiciones de seguridad de un circuito de rollup.

Un sistema de pruebas de la capa base es, por tanto, un problema de coordinación mayor. Requiere especificaciones, clientes, redes de prueba, auditorías y acuerdo entre los participantes.

La frase de Buterin «computadora mundial criptográfica» es una dirección de viaje, no una afirmación de que un solo servicio de pruebas ejecutará Ethereum.

El estado sigue siendo el problema difícil

Buterin identifica el acceso a un estado compartido muy grande como uno de los problemas no resueltos más difíciles de Ethereum.

Una prueba puede atestiguar que un cálculo se hizo correctamente. Pero el probador aún necesita la información usada en ese cálculo: saldos, almacenamiento de contratos, datos de cuentas y otro estado.

Si muchas transacciones tocan el mismo estado a la vez, dividir el trabajo se vuelve difícil. Un pago de una cuenta y un intercambio contra un fondo de liquidez no pueden finalizarse a partir de instantáneas inconsistentes.

Por eso la escala no es solo un problema de generación de pruebas.

El cálculo paralelo funciona mejor cuando las tareas pueden separarse limpiamente. El estado compartido crea dependencias. Dos usuarios que operan contra el mismo fondo con poca liquidez pueden recibir precios diferentes según el orden. Ninguna prueba hace que esas dos órdenes sean económicamente equivalentes.

Un probador más rápido ayuda. No resuelve por sí solo la contención de estado, la censura, el ordenamiento o la disponibilidad de datos.

La privacidad tampoco es automática

La visión de Buterin incluye componentes descentralizados fuera de la cadena y una mejor privacidad criptográfica.

Eso no significa que las pruebas de validez hagan automáticamente privada a Ethereum.

Las entradas públicas, el comportamiento de las carteras, el momento de las transacciones y los metadatos de red pueden seguir revelando información. Un pago puede verificarse matemáticamente y aun así filtrar datos útiles sobre el remitente o el destinatario.

La privacidad requiere mecanismos separados. Un sistema debe especificar qué datos se ocultan, quién puede acceder a ellos, cómo se construyen las pruebas y qué metadatos permanecen visibles.

Lo mismo ocurre con la infraestructura fuera de la cadena. Una capa intermedia descentralizada puede mejorar el rendimiento y la privacidad, pero debe definir quién puede unirse, cómo se distribuyen los datos y qué pueden hacer los usuarios si el sistema falla.

La criptografía puede reducir la confianza. No elimina las decisiones de diseño.

Cómo se puede probar la independencia

La afirmación de que «cualquiera puede verificar» tiene requisitos prácticos.

Un nodo ordinario necesita código de verificador, entradas públicas, acceso al estado de cadena aceptado y suficiente capacidad de procesamiento para comprobar pruebas dentro de los límites de tiempo del protocolo.

Varias pruebas importan antes de cualquier bifurcación final.

Ejecutar software de verificador de más de un equipo de clientes contra la misma prueba de bloque válida. Confirmar que ambos la aceptan. Cambiar las entradas públicas y confirmar que ambos la rechazan. Preguntar si equipos de probadores separados pueden generar pruebas aceptadas bajo las mismas reglas, con qué rapidez pueden hacerlo y qué hardware requieren.

Luego repetir el proceso en redes de prueba públicas bajo carga.

Estos no son criterios oficiales de lanzamiento. Son señales observables de si la validación basada en pruebas está lista.

La independencia también significa que un usuario puede obtener los datos necesarios 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 el camino desde los datos de la cuenta hasta esa raíz sigue dependiendo de otra persona para una comprobación práctica del saldo.

El programa que se prueba debe ser el correcto

Una prueba solo es tan útil como la afirmación que demuestra.

Los usuarios necesitan confianza en que el código del verificador es público, en que las actualizaciones están controladas y en que el circuito refleja las reglas que creen que la red está aplicando.

Un hash público del código del verificador, un proceso de actualización claro y pruebas de circuito independientes ayudan a los observadores externos a comparar las reglas anunciadas con lo que los nodos realmente aplican.

La verificación formal puede reducir el riesgo de errores lógicos, pero comienza con una especificación escrita por humanos.

La afirmación final no es «la criptografía resolvió la confianza». La afirmación más fuerte es más estrecha y más útil: un resultado especificado puede rechazarse de forma independiente cuando la evidencia es inválida, sin que cada nodo pague el coste de producir ese resultado.

Hegota es un marcador, no una garantía

Buterin se refiere a Hegota, una bifurcación planeada para 2027, como posiblemente la última actualización cuyos componentes resultarían familiares a un observador de Ethereum de 2015.

Después de eso, su hoja de ruta apunta hacia STARKs recursivos, verificación formal, consenso optimizado y seguridad cuántica. Crypto.news ha cubierto por separado el objetivo de seguridad cuántica de Ethereum para 2029 como meta de planificación.

Nada de eso garantiza la entrega para 2030.

Las actualizaciones de Ethereum requieren especificaciones, implementaciones de clientes, redes de prueba, revisiones de seguridad y coordinación en todo el ecosistema. Una hoja de ruta puede identificar el trabajo. No activa el trabajo en la cadena.

PeerDAS puede verificarse hoy a través de Fusaka y las reglas actuales de los nodos. Un zkEVM general de capa base no puede verificarse leyendo un ensayo. La evidencia llegará a través de especificaciones, implementaciones, pruebas públicas y un plan de bifurcación concreto.

La dirección es clara, pero la prueba es práctica

El argumento a favor del futuro de Ethereum con muchas pruebas es fuerte.

Si la verificación se vuelve barata y los datos pueden muestrearse de forma segura, más usuarios podrán comprobar de forma independiente un sistema más grande sin necesitar máquinas proporcionales a toda la computación y los datos de Ethereum.

Esa es la ventaja.

El desafío es que las pruebas no operan solas. La pila de pruebas debe ser segura, rápida y producida de forma competitiva. Los datos deben permanecer disponibles. Los usuarios deben tener vías para enviar transacciones. El ordenamiento debe manejarse con suficiente transparencia para limitar el abuso. El protocolo debe sobrevivir a los fallos de los probadores sin convertir a un actor especializado en un punto oculto de control.

Una red con verificación barata pero un único probador o secuenciador indispensable puede seguir siendo frágil.

La prueba real para los usuarios es simple: ¿puede un participante independiente ordinario rechazar un mal resultado, recuperar los datos necesarios para conocer su propio estado y enviar una transacción a pesar de cualquier operador?

Cada respuesta requiere un mecanismo separado. La prueba es solo una parte del sistema. Su poder proviene de permitir que las personas que no hicieron el trabajo pesado comprueben si el resultado es válido.