Resumen
Ejecución Stateless: Los validadores no almacenan todo el estado, sino que solo verifican las transiciones a través de pruebas criptográficas.
Ejecución Stateful: Cada validador almacena y actualiza todo el estado del sistema (modelo tradicional de la mainnet de Ethereum).
Stateless se basa en pruebas compactas (árboles Verkle, STARKs) y en una capa de datos de disponibilidad (DA) robusta.
La principal ventaja: costo de hardware mucho más bajo + mayor descentralización en comparación con el tamaño de prueba y mayor ancho de banda.
Realidad 2025: El modelo Stateless puro sigue siendo raro; la mayoría de la arquitectura modular utiliza la ejecución Stateless combinada con DA/estado (modelo mixto).
Ejemplo típico: Ethereum Verge (Verkle), Polygon AggLayer, rollups en Celestia, y puentes perezosos (lazy bridging)
¿Por qué es importante el modelo de ejecución?
La forma en que los nodos de blockchain acceden y actualizan el estado ya no es un detalle de implementación simple; se convierte en una de las principales herramientas para escalar y lograr soberanía en el diseño modular. A medida que los rollups, appchains, y L2 soberanos evolucionan, los arquitectos deben decidir si los validadores necesitan llevar terabytes de datos históricos o si pueden verificar el estado de transición sin almacenar el estado.
La elección entre Stateless y Stateful afecta directamente la descentralización, las barreras de hardware, los costos de disponibilidad de datos, y la capacidad de interoperabilidad entre cadenas.
Definición 2 Modelos
Ejecución Stateful – Modelo Tradicional
En el modelo Stateful, cada nodo completo mantiene una copia actualizada completa de todo el estado del sistema (saldos de cuentas, almacenamiento de contratos inteligentes, código hash, etc.). Cuando se propone un bloque:
El productor de bloques incluye la transacción y el nuevo root de estado.
Cada validador vuelve a ejecutar cada transacción en una copia del estado local.
Si el root de estado resultante coincide con el root en el bloque, el bloque es aceptado.
Ethereum, Solana, BNB Chain, y la mayoría de los L1 monolíticos funcionan de esta manera. La ventaja es la simplicidad y la confirmación de estado instantánea: cualquier nodo puede responder "¿cuánto es el saldo de la dirección X?" sin necesidad de comunicarse con ningún otro.
Desventaja clara en 2025: Un nodo completo de Ethereum actualmente supera los 14 TB y sigue aumentando. Incluso los nodos que han sido podados requieren SSD ~1 TB y RAM 32+ GB, lo que elimina la capacidad de operación de la mayoría de los usuarios individuales.
Ejecución Stateless
En el modelo Stateless, los validadores no almacenan el estado del sistema localmente. En cambio, cada transacción (o lote) viene con una prueba criptográfica que confirma que la transacción tiene acceso a las partes del estado necesarias (por ejemplo: rama Merkle en el árbol Patricia o prueba Verkle).
El proceso de verificación se convierte en:
El productor de bloques adjunta prueba + transacción + nuevo root de estado.
Los validadores verifican la validez de la prueba frente al root de estado aceptado más cercano.
Los validadores vuelven a ejecutar las transacciones solo con los datos de prueba proporcionados.
Si el root de estado calculado coincide con la declaración en el bloque, se acepta.
Ningún nodo almacena más de unos pocos bloques de estado recientes. La carga se desplaza de almacenamiento a ancho de banda y verificación criptográfica.
Consideraciones Técnicas al Escalar
Requisitos de Hardware y Descentralización
Stateless tiene una clara ventaja en este aspecto. Un cliente Ethereum Stateless está siendo probado en la red testnet Verge y puede funcionar sin problemas en un mini-PC de 300 USD o incluso en un clúster de Raspberry Pi 5 de gama alta. Mientras tanto, ejecutar un nodo Stateful en la mayoría de L1/L2 requiere hardware empresarial.
Prueba de la realidad: Los nodos DA ligeros de Celestia han funcionado Stateless con <8 GB de RAM, mientras que los nodos de ejecución de Ethereum luchan con el problema de la inflación del estado.
Ancho de banda y Tamaño
La principal desventaja de la ejecución Stateless pura siempre ha sido el problema de la prueba inflacionaria. Con el árbol Merkle-Patricia clásico de Ethereum, una sola transacción ERC-20 a menudo requiere ~1–3 KB de datos de prueba. Incluso con 1,000 transacciones/segundo, esto se traduce en decenas de megabits/segundo solo para la prueba, superando el umbral práctico para el cliente Stateless.
Esa es la razón por la que todo el ecosistema está compitiendo para adoptar árboles Verkle y recursión STARK: ambos reducen el tamaño de la prueba en 20–30× y hacen que el cliente Stateless sea viable a escala práctica.
Aseguramiento de la Disponibilidad de Datos
Cliente Stateless solo es seguro mediante la capa de disponibilidad de datos base. Si el productor de bloques oculta parte de la prueba o delta de estado, el validador Stateless no puede detectar fraudes sin los datos completos.
Esta es la razón por la que la ejecución Stateless casi siempre se combina con una capa DA dedicada (Celestia, Ethereum DAS después de Praga, Avail). La capa DA sigue siendo Stateful, lo que significa que debe almacenar y servir datos, pero los validadores de ejecución se mantienen ligeros y Stateless.
Compatibilidad Sincrónica & Asincrónica
Rollups Stateful (por ejemplo: Arbitrum One antes de Atlas, cadena OP Stack) proporcionan compatibilidad: un token en este rollup puede ser utilizado en otro rollup en el mismo bloque si comparten una capa de pago común.
El diseño Stateless tiende a inclinarse hacia la compatibilidad asincrónica porque la prueba de estado lleva tiempo para generar y propagar. Proyectos como Polygon AggLayer y el puente SP1 de Succinct están abordando esto con mecanismos de confirmación previa y un puente Stateless común.
Implementación Práctica
Ethereum – Árboles Verkle
La próxima actualización "Verge" de Ethereum reemplaza el árbol Patricia Merkle por árboles Verkle, reduciendo el tamaño de la prueba de kilobytes a ~30–50 bytes por celda de almacenamiento. El EIP-6800 y el EIP-7691 sientan las bases para un cliente Stateless completo para 2026–2027. Una vez implementado, cualquiera podrá ejecutar un nodo de verificación completo en una laptop mientras sigue verificando toda la cadena.
Celestia + Rollups – DA Stateless, Ejecución Mixta
Celestia completamente Stateless para el muestreo de disponibilidad de datos. Los rollups que se registran en Celestia (por ejemplo: Doma, Movement) actualmente ejecutan un nodo Stateful, pero proyectos como Eclipse y Citrus (rollup SVM en Celestia) están cambiando a clientes SVM Stateless utilizando pruebas STARK y DA Celestia.
Polygon AggLayer – Puente Stateless Multifuncional
AggLayer implementa un conjunto común de pruebas Stateless. Las cadenas separadas pueden mantener estado interno, pero los mensajes entre cadenas se prueban a través de ZK Stateless basado en el root de estado común. Esto proporciona la seguridad de una capa de pago común sin obligar a cada validador a almacenar el estado de cada cadena.
Métodos Mixtos – Solución Práctica
La ejecución puramente Stateless sigue siendo rara en producción. La mayoría de los equipos adoptan uno de los tres modelos mixtos:
Ejecución Stateful + verificación Stateless (por ejemplo: el prover boojum de zkSync Era genera pruebas que cualquier nodo Stateless puede verificar)
Cliente Stateless + DA/estado base (modelo Ethereum + Celestia)
Capa de puente Stateless sobre cadenas Stateful (AggLayer, firma en cadena de Near)
Estos modelos mixtos capturan la mayoría de los beneficios de descentralización mientras controlan los costos de prueba.
Implementación en el Futuro
Para 2027, la suposición predeterminada en la arquitectura modular podría ser "ejecución Stateless, disponibilidad de datos y pagos mínimos Stateful". Los avances en árboles Verkle, recursión STARK, y la distribución de pruebas descentralizadas (por ejemplo: Red Portal, cliente ligero Helios) están eliminando los últimos grandes obstáculos.
Para los constructores que eligen el modelo de ejecución hoy:
Si se prioriza al máximo la descentralización y la soberanía a largo plazo → optar por Stateless desde el principio (combinado con Celestia/Avail/Ethereum DAS)
Si se necesita compatibilidad y se acepta hardware más alto → ejecución Stateful con poda de datos robusta y un camino de transición hacia Stateless
El modelo Stateless no es una solución universal, pero se está convirtiendo en un requisito previo para cualquier cadena que desee mantener la neutralidad y la accesibilidad global a medida que el estado crece indefinidamente.
El futuro de la cadena de bloques escalable y soberana es donde ninguna entidad, por muy bien financiada que esté, necesita almacenar todo el historial de la cadena para participar en el consenso. Ese futuro se está construyendo.