Puntos Esenciales
- La validación sin estado permite que un nodo verifique bloques en una blockchain usando únicamente una prueba criptográfica compacta, sin necesidad de almacenar todo el historial del estado de la red.
- El mecanismo central es el «testigo» o witness: un paquete de datos mínimos que demuestra criptográficamente que cierta información es correcta, sin exponer el estado completo.
- Esta tecnología es crucial porque el crecimiento del estado de redes como Ethereum hace que ejecutar un nodo completo sea cada vez más costoso, amenazando la descentralización real de la red.
- La idea lleva debatiéndose desde 2017 en los foros de investigación de Ethereum y ya tiene implementaciones reales: NEAR Protocol la activó en mainnet en agosto de 2024, mientras Ethereum avanza hacia ella mediante las Verkle Trees.
La infraestructura de las redes blockchain enfrenta una contradicción fundamental que se agrava con cada bloque que se añade a la cadena. Para que una red sea verdaderamente descentralizada, cualquier persona en el mundo debería poder verificar su estado de forma independiente. Sin embargo, ejecutar un nodo completo en redes como Ethereum requiere hoy más de un terabyte de almacenamiento rápido, 16 GB de RAM y una conexión de banda ancha estable. El hardware necesario cuesta miles de euros, lo que concentra la validación en un número reducido de operadores técnicos y con recursos suficientes.
La validación sin estado, conocida en inglés como stateless validation o stateless clients, es la respuesta técnica más prometedora a esta tensión. El concepto es conceptualmente elegante: separar la capacidad de verificar el estado de la red de la obligación de almacenarlo. Si un nodo puede comprobar que un bloque es válido sin necesitar una copia local de toda la información acumulada desde el bloque génesis, el acceso a la red se democratiza radicalmente. Este artículo explora qué es exactamente la validación sin estado, quién la introdujo, cómo funciona a nivel técnico y qué redes blockchain la están implementando hoy.
El problema del estado creciente: por qué los nodos se vuelven más pesados con el tiempo
Para entender la validación sin estado, es necesario comprender primero qué es el «estado» de una blockchain. En una red como Ethereum, el estado es el conjunto completo de información actualizada en cada momento: los saldos de todas las carteras, el código de todos los contratos inteligentes desplegados y los datos almacenados por esos contratos. No es el historial de transacciones —eso es la cadena de bloques propiamente dicha— sino el resultado acumulado de aplicar todas esas transacciones desde el principio.
El problema es que el estado crece. Cada contrato desplegado, cada cartera activa, cada operación de almacenamiento en un protocolo DeFi añade datos al estado global. Ethereum utiliza una estructura de datos llamada Merkle Patricia Trie para organizar este estado, lo que permite verificar que cualquier dato concreto forma parte del estado sin leerlo todo. Sin embargo, para producir esa prueba —lo que se llama un «testigo» o witness— y verificar un bloque completo, el nodo necesita acceso a una porción significativa del estado que ese bloque modifica.
A medida que el estado crece, el coste de operar un nodo completo sube. Validar bloques requiere consultar partes del estado distribuidas a lo largo de la estructura de datos, y mantener esa estructura actualizada y disponible en disco consume recursos considerables. Este fenómeno se conoce como state bloat, o hinchazón del estado, y fue identificado como uno de los problemas estructurales más serios de Ethereum ya en 2017 por su co-fundador Vitalik Buterin, cuando la congestión provocada por el éxito de CryptoKitties hizo evidente que los nodos completos eran demasiado costosos para la mayoría de usuarios.
Qué es la validación sin estado: la lógica del testigo criptográfico
La validación sin estado propone un cambio conceptual: en lugar de que cada nodo mantenga una copia local del estado completo para verificar los bloques, el bloque mismo llega acompañado de todo lo que el nodo necesita para validarlo.
Ese paquete de datos se llama witness, o testigo en español. Un witness incluye dos elementos fundamentales: los valores concretos del estado que el bloque va a leer o modificar —saldos, código de contratos, datos de almacenamiento— y una prueba criptográfica que demuestra que esos valores son genuinamente parte del estado global y no han sido fabricados por quien propuso el bloque. El nodo verificador utiliza el witness para ejecutar las transacciones del bloque, comprueba que el resultado es coherente y descarta los datos una vez terminada la verificación. No necesita guardarlos.
La diferencia es análoga a la que existe entre un auditor que necesita tener acceso al archivo completo de una empresa para verificar una transacción concreta, y un auditor que recibe únicamente el extracto relevante junto con una firma notarial que garantiza su autenticidad. El segundo puede hacer exactamente el mismo trabajo de verificación con una fracción de los recursos.
El concepto apareció formalmente en el ecosistema Ethereum alrededor de 2017-2018, cuando Buterin comenzó a publicar notas de investigación sobre el problema del estado creciente. Alexey Akhunov, uno de los desarrolladores de clientes de Ethereum, fue uno de los primeros en proponer que los clientes sin estado podrían implementarse sin necesidad de un hard fork, simplemente modificando cómo los clientes gestionan y transmiten datos. En una publicación de esa época, Buterin reconoció explícitamente su cambio de posición: «Ahora estoy a favor del enfoque de clientes sin estado». Desde entonces, la investigación no ha parado, aunque la implementación práctica ha requerido superar obstáculos criptográficos considerables.
El obstáculo central: el tamaño del witness
Si el concepto es tan lógico, ¿por qué llevó más de seis años desde la idea hasta las primeras implementaciones reales? La respuesta está en el tamaño del witness y las estructuras de datos que lo hacen posible.
Con la estructura actual de Ethereum —el Merkle Patricia Trie— generar un witness para todas las lecturas y escrituras que ocurren en un bloque típico produce un paquete de datos demasiado grande. La razón es estructural: en un árbol de Merkle, demostrar que un dato pertenece al árbol requiere incluir todos los nodos hermanos a lo largo del camino desde la hoja hasta la raíz. Si un bloque accede a decenas o cientos de datos distintos en distintas ramas del árbol, los caminos se multiplican y el witness se infla rápidamente hasta el punto de ser impracticable para transmitirse dentro del tiempo de bloque disponible.
La solución que el ecosistema Ethereum ha identificado como más prometedora son las Verkle Trees. Su nombre es un acrónimo de «Vector commitment Merkle Trees», y representan una variante de árbol que utiliza compromisos polinomiales —específicamente, compromisos KZG— en lugar de funciones hash para generar las pruebas. La ventaja crítica es que en un árbol Verkle, múltiples datos pueden demostrarse como parte del árbol mediante una única prueba compacta de tamaño fijo, independientemente del número de elementos que se quieran verificar simultáneamente. Según la documentación oficial de Ethereum, para un árbol con mil millones de datos, un árbol Verkle puede generar una prueba de menos de 150 bytes, mientras que un árbol de Merkle equivalente necesitaría varios kilobytes por elemento.
Certificado
Cómo funciona la validación sin estado paso a paso
El flujo de la validación sin estado sigue una secuencia bien definida que diferencia claramente los roles de quienes producen bloques y quienes los verifican.
El proceso comienza con el productor del bloque, que sí mantiene acceso al estado completo. Es quien conoce todos los datos necesarios para ejecutar las transacciones. Al construir el bloque, el productor no solo empaqueta las transacciones, sino que también genera el witness: recopila todos los datos del estado que esas transacciones leen o modifican, construye las pruebas criptográficas que demuestran que esos datos son auténticos, y adjunta todo al bloque antes de transmitirlo a la red.
El nodo verificador recibe el bloque junto con su witness. Sin consultar ninguna base de datos local, ejecuta las transacciones usando exclusivamente los datos contenidos en el witness, verifica que las pruebas criptográficas son correctas, y comprueba que el estado resultante coincide con el que el productor del bloque ha declarado. Si todo cuadra, el bloque es válido. El nodo puede entonces descartar el witness y continuar esperando el siguiente bloque.
Este diseño tiene una implicación de gran alcance: separa definitivamente la función de producir bloques —que sigue requiriendo acceso al estado completo— de la función de verificarlos, que pasa a ser ligera y accesible. En la jerga del ecosistema, esto se conoce como «weak statelessness» o estatelessness débil: no todos los nodos eliminan la necesidad de almacenar estado, pero los que solo verifican (la mayoría) pueden hacerlo sin esa carga.
Implementaciones actuales: quién está haciendo stateless validation hoy
La validación sin estado ha pasado del papel a la realidad en varias redes. Los casos más relevantes ofrecen perspectivas distintas sobre cómo implementar el concepto según las necesidades de cada arquitectura.
- NEAR Protocol y Nightshade 2.0 representa el ejemplo más maduro de stateless validation en producción a gran escala. En agosto de 2024, NEAR lanzó Nightshade 2.0 en mainnet, describiéndolo como el mayor cambio al protocolo desde su lanzamiento en octubre de 2020. La implementación introduce lo que NEAR llama «chunk validation stateless»: los validadores de la red ya no necesitan mantener el estado completo de ningún fragmento (shard) del que sean responsables. En su lugar, los productores de chunks —quienes construyen las porciones de bloque de cada shard— generan un state witness que acompaña al chunk, y los validadores usan ese witness para verificar la transición de estado sin necesitar datos locales. El impacto práctico es significativo: los requisitos de hardware para operar un validador se reducen notablemente, la red puede expandir su número de shards con mayor facilidad y la barrera de entrada para participar en la validación disminuye. Según la documentación de Messari sobre Nightshade 2.0 (agosto 2024), el upgrade permite a NEAR pasar de seis a diez shards y mejora el rendimiento de cada shard individual de forma sustancial.
- Ethereum y The Verge representa el camino hacia stateless validation más seguido por la comunidad técnica global. La hoja de ruta de Ethereum incluye una fase llamada «The Verge», que tiene como objetivo central hacer posible la verificación completa de la cadena sin necesidad de almacenar cientos de gigabytes de estado. El mecanismo principal es la migración del estado actual —en Merkle Patricia Tries— hacia Verkle Trees, especificada en el EIP-6800. Los equipos de clientes de Ethereum —incluyendo Geth, Erigon y Nimbus— llevan años trabajando en esta transición. En julio de 2025, la Ethereum Foundation anunció que todos los clientes de ejecución soportan la expiración parcial de historial según el EIP-4444, un paso preliminar que reduce el almacenamiento en cientos de gigabytes por nodo aunque no implica todavía statelessness completa. Buterin ha descrito el objetivo final con notable ambición: que cualquier wallet móvil, navegador web o incluso un smartwatch pueda verificar la cadena de Ethereum de forma completa por defecto.
- Polygon y PIP-72 ilustra cómo la idea se extiende hacia redes compatibles con EVM. En agosto de 2025, el foro de gobernanza de Polygon publicó el PIP-72, una propuesta formal para introducir verificación stateless basada en witnesses criptográficos en la red Polygon, habilitando nodos que validen bloques sin mantener el estado completo de la blockchain.
Por qué la validación sin estado es tan necesaria en el sector cripto
El argumento de fondo no es puramente técnico: es político en el sentido más profundo del término. La premisa de una red blockchain descentralizada es que ninguna entidad controla quién puede participar en su validación. Sin embargo, cuando ejecutar un nodo completo requiere hardware especializado de varios miles de euros y conectividad de alta velocidad, el conjunto de validadores reales tiende a concentrarse en centros de datos, grandes operadores y pools profesionales. Esto no invalida la descentralización técnica del protocolo, pero sí la descentralización práctica de quién puede auditar el estado de la red de forma independiente.
La validación sin estado ataca directamente este problema. Si verificar un bloque requiere procesar un witness de pocos kilobytes en lugar de consultar un estado de terabytes, el hardware necesario cae a niveles alcanzables por hardware de consumo. Según la documentación de Nimbus (abril 2025), clientes stateless bien implementados podrían eventualmente operar en dispositivos modestos, incluyendo hardware de consumo básico, lo que aumenta el número de verificadores independientes y hace la red más resistente a la censura y a la captura por entidades con grandes recursos.
Existe también un argumento de escalabilidad. El crecimiento indefinido del estado supone un límite práctico al rendimiento de las redes: cuantos más datos almacena un nodo, más lentas son las lecturas y escrituras durante la validación. La validación sin estado no elimina la necesidad de que alguien almacene el estado completo —los productores de bloques siguen necesitándolo— pero descarga esa responsabilidad de los verificadores, aligerando el cuello de botella en la capa de validación.
Por último, la stateless validation es la condición previa para un ecosistema de clientes ligeros genuinamente seguros. Hoy, los usuarios que acceden a Ethereum a través de una cartera en el móvil confían en nodos de terceros para obtener información del estado. Con stateless clients maduros, esas carteras podrían verificar ellas mismas la validez de la información que reciben, sin necesidad de confiar en ningún intermediario, lo que representa un avance significativo en el modelo de seguridad real del usuario final.
Estado actual: stateless validation en 2026
A principios de 2026, el panorama de la validación sin estado puede describirse como heterogéneo pero con impulso claro. NEAR Protocol tiene stateless validation operativa en su mainnet desde agosto de 2024 y continúa expandiendo el número de shards. Ethereum avanza en The Verge: la migración a Verkle Trees está en fase de testnet activa, con clientes como Geth, Erigon y Nimbus con implementaciones en curso según las últimas actualizaciones públicas de los equipos (enero 2025). El EIP-4444 —que reduce la carga histórica de los nodos aunque no implementa statelessness completa— ya tiene soporte en todos los clientes de ejecución de Ethereum desde julio de 2025.
Un paper publicado en ArXiv en abril de 2025 («Towards Stateless Clients in Ethereum: Benchmarking Verkle Trees and Binary Merkle Trees with SNARKs») comparó las dos aproximaciones técnicas más debatidas: Verkle trees con compromisos vectoriales, y árboles de Merkle binarios combinados con SNARKs. Los benchmarks evalúan tiempo de generación de pruebas, tamaño del witness y tiempo de verificación, y sus resultados apuntarán los próximos pasos del debate técnico en Ethereum.
La pregunta que permanece abierta no es si la validación sin estado llegará a las principales redes blockchain, sino cuándo y bajo qué forma exacta. La complejidad de migrar el estado existente de Ethereum —con sus cientos de gigabytes ya almacenados en Merkle Patricia Tries— hacia una nueva estructura de Verkle Trees sin interrumpir el funcionamiento de la red es uno de los retos de ingeniería más complejos que la comunidad blockchain haya afrontado.
Autor
