El modelo de almacenamiento perpetuo que adoptaron las primeras blockchains contiene una contradicción que se vuelve más evidente con cada ciclo de adopción. Exigir que cada nodo validador conserve la totalidad del estado —el conjunto de saldos, nonces y almacenamiento de contratos accesible en el bloque más reciente— sin ningún mecanismo de vencimiento equivale a imponer una carga asintótica sobre los operadores.
Con el tiempo, esa carga transforma la verificación independiente en un privilegio de infraestructura. La caducidad del estado no es una optimización cosmética: constituye la respuesta técnica a la pregunta de cómo un protocolo permissionless puede preservar la verificabilidad cuando el uso se mide en décadas.
Para entender la magnitud del problema conviene separar dos componentes que suelen confundirse. El historial de transacciones es un registro secuencial que puede podarse, archivarse o distribuirse sin afectar la validación del presente.
El estado es la fotografía actualizada de todo aquello que una transacción puede leer o modificar directamente: cada cuenta, cada slot de almacenamiento de cada contrato, cada entrada en un mapa.
Validar un bloque requiere acceso aleatorio de baja latencia a fragmentos arbitrarios del estado. Por eso el estado debe residir en discos SSD y, en buena medida, en memoria RAM de los nodos completos. Mientras el historial admite soluciones de almacenamiento frío, el estado impone costos de hardware que crecen de forma monótona.
La expansión inercial del estado es consecuencia directa de la permanencia de los datos. Un nuevo usuario, un nuevo token o una nueva posición en un protocolo DeFi añaden entradas que, incluso cuando dejan de utilizarse, no desaparecen. Las operaciones que liberan espacio en lenguajes de alto nivel a menudo se traducen en escrituras que ponen a cero una variable, sin eliminar el slot del árbol de estado subyacente.
La experiencia de Ethereum resulta ilustrativa: el estado ha pasado de unos pocos gigabytes en 2016 a varios cientos de gigabytes en la actualidad. Esa tendencia incrementa los requisitos de almacenamiento, eleva los tiempos de sincronización y, sobre todo, reduce el número de actores capaces de operar un nodo completo de validación.
La concentración de nodos en centros de datos y proveedores de nube representa la consecuencia más lesiva. Cuando los costos de hardware excluyen a los participantes con equipos de consumo, el principio de “no confíes, verifica” se degrada hacia una arquitectura donde la mayoría de los usuarios delega la verificación en infraestructura ajena, a menudo centralizada en pocos proveedores de RPC.
La presión centralizadora inducida por el estado opera de manera silenciosa, sin requerir cambios de protocolo ni actores maliciosos. Basta con que el costo incremental expulse a los validadores domésticos para que la capa de consenso repose sobre un conjunto cada vez más homogéneo de entidades.
Ante este diagnóstico, eliminar sin más el estado antiguo no constituye una opción viable. Si un nodo descarta la información correspondiente a una cuenta que lleva años inactiva, se vuelve incapaz de validar una transacción futura que involucre esa cuenta. Desconocer el saldo y el nonce impide discernir si la operación es legítima o si constituye un intento de doble gasto.
Recalcular el estado desde el bloque génesis para restaurar una sola cuenta resulta computacionalmente prohibitivo. La clave técnica reside, por tanto, en transferir la carga de almacenamiento desde el consenso hacia el usuario, sin sacrificar la capacidad de verificación de los validadores. Eso es lo que persigue la caducidad del estado.
La caducidad del estado define una frontera temporal: los datos que no han sido accedidos durante un período preestablecido pasan de formar parte del estado activo que los validadores deben mantener a una capa de almacenamiento secundaria.
El estado activo se mantiene acotado, mientras que el estado expirado no se destruye: permanece disponible en repositorios externos y puede ser resucitado cuando el titular de la cuenta decide interactuar de nuevo con la red. Esta arquitectura se sostiene sobre un cambio en las estructuras de datos criptográficos que permiten probar la pertenencia de un valor al estado sin necesidad de almacenar el árbol completo.
Los árboles de Verkle constituyen el habilitador fundamental de ese cambio. A diferencia de los árboles de Merkle-Patricia actuales, los compromisos vectoriales basados en Verkle producen pruebas de tamaño reducido —del orden de unos pocos cientos de bytes— que permiten demostrar el valor de una clave y, al mismo tiempo, que esa clave no ha sido modificada desde el momento de la expiración.
Cuando un usuario desea reactivar una cuenta dormida, adjunta un testigo (witness) con la prueba criptográfica del último estado válido. Los validadores verifican el testigo sin haber almacenado el dato expirado y, tras la comprobación, incorporan la cuenta al estado activo. La red no conserva el estado perpetuo; conserva la capacidad de validar su resurrección bajo demanda.
El plan de trabajo descrito por los investigadores de Ethereum introduce, además, una modificación en el formato de las direcciones para incluir un marcador de época. Este marcador permite determinar sin ambigüedad si una cuenta pertenece a un período ya expirado y qué raíz de Verkle debe utilizarse para verificar el testigo.
El mecanismo de expiración por época segmenta el estado en función del último acceso y proporciona un camino claro para que el software de billetera gestione testigos de manera automática. El usuario no necesita comprender la infraestructura subyacente; la billetera almacena o recupera el testigo cuando corresponde.
La combinación de validación sin estado y caducidad progresiva ofrece una perspectiva de escalado que desacopla los requerimientos del validador del crecimiento acumulado de la red. En un esquema completamente sin estado, los validadores no conservarían ningún estado y recibirían testigos con cada transacción.
La caducidad del estado puede entenderse como una implementación híbrida: los validadores mantienen el estado caliente —el que se modifica con frecuencia— y exigen testigos solo para los datos que han superado el umbral de inactividad. El resultado es un tamaño acotado del estado activo que puede fijarse en un valor compatible con discos de consumo, por ejemplo entre 20 y 50 GB. Con ese límite, operar un nodo validador completo sigue siendo factible para cualquier persona con una conexión de banda ancha estándar y un ordenador portátil.
Los desafíos que plantea este modelo no son triviales y se concentran en tres áreas: disponibilidad de testigos, experiencia de usuario y dependencia de contratos inactivos. La disponibilidad de testigos requiere que existan nodos de archivo o proveedores de estado que conserven los datos expirados y generen las pruebas bajo demanda.
Si esos proveedores se consolidan en un número reducido de entidades, aparece un nuevo vector de centralización, aunque de naturaleza distinta: no afecta a la validación del consenso, pero sí a la capacidad de los usuarios para recuperar sus cuentas de forma autónoma. Mitigar ese riesgo exige protocolos de distribución de testigos que permitan a las billeteras almacenar su propia prueba en el momento de la expiración o replicarla en redes descentralizadas de almacenamiento.
La experiencia de usuario se modifica porque el titular de una cuenta que permanece inactiva durante años debe conservar o poder recuperar el testigo correspondiente. Las billeteras deberán incorporar flujos de resurrección automática que abstraigan esa complejidad. Un usuario que recibe un activo en una dirección dormida y desconoce el mecanismo de testigos podría encontrar que la transacción requiere un paso adicional de reactivación.
La evolución de los estándares de billetera y la comunicación con los exchanges resultan imprescindibles para que la caducidad no se traduzca en fricción operativa.
El tercer desafío atañe a los contratos inteligentes de baja frecuencia de uso pero alta relevancia sistémica. Un contrato de gobernanza que solo se invoca durante situaciones excepcionales podría expirar entre votaciones. El costo de resurrección —tanto en gas como en provisión de testigos— debe ser lo suficientemente bajo para que la reactivación no introduzca barreras económicas.
Los diseñadores del protocolo estudian mecanismos que permitan a los propios contratos pagar por su permanencia en el estado activo o delegar en terceros la renovación periódica mediante transacciones de “keep-alive” económicamente racionales.
Las alternativas previas a la caducidad del estado basada en testigos, como el alquiler de estado, intentaron abordar la expansión mediante pagos recurrentes por el almacenamiento. Ese camino generó rechazo por los efectos sobre la propiedad: la posibilidad de perder un NFT o un saldo por no abonar una tasa periódica contradice expectativas fundamentales de los usuarios.
La caducidad con testigos invierte la lógica: el dato no se pierde, pero su custodia se transfiere al interesado. El protocolo deja de garantizar el almacenamiento perpetuo y pasa a garantizar la verificabilidad perpetua. Esa distinción resulta central para comprender el cambio de paradigma.
La implementación de la caducidad del estado requiere modificar la capa de ejecución, actualizar las estructuras de datos del estado global y coordinar una transición en el formato de direcciones. El calendario técnico de Ethereum sitúa la migración a árboles de Verkle como paso previo necesario, seguido por la introducción progresiva de la expiración por época. La comunidad de desarrolladores de clientes y los equipos de investigación trabajan en prototipos que permitan evaluar los costos de resurrección y la sobrecarga de ancho de banda asociada a la inclusión de testigos en las transacciones.
Los resultados preliminares indican que el incremento en el tamaño de los bloques por la inclusión de testigos resulta manejable, en especial si se aplican esquemas de agregación de pruebas.
La relevancia de este debate trasciende a Ethereum. Otras arquitecturas de capa uno que aspiran a mantener nodos completos en dispositivos de consumo enfrentan el mismo cuello de botella. La preservación de la descentralización de la validación exige en todas ellas un compromiso explícito con la acotación del estado.
Los diseños que postergan esta discusión mientras se enfocan exclusivamente en el aumento del rendimiento mediante ejecución paralela o disponibilidad de datos externa están acumulando una deuda técnica que se manifestará cuando el estado activo supere las capacidades del hardware accesible para el operador independiente.
La caducidad del estado constituye, en última instancia, una decisión de arquitectura sobre quién soporta el costo del paso del tiempo en una red descentralizada. Si ese costo se socializa entre todos los validadores, el resultado es una presión constante hacia la centralización de la infraestructura.
Si, por el contrario, se asigna a quien genera la demanda de permanencia, el sistema puede fijar un límite superior al estado activo y mantener la verificabilidad en equipos de bajo costo. La tecnología de testigos y árboles de Verkle ofrece por primera vez una vía para implementar esa asignación sin sacrificar la capacidad de validación sin confianza.
Un protocolo que no incorpora caducidad del estado puede funcionar durante años sin signos evidentes de deterioro, pero acumula una fragilidad estructural que se vuelve irreversible cuando los operadores domésticos abandonan la red. La historia de los sistemas distribuidos muestra que la complejidad de la coordinación para introducir cambios de este calibre crece exponencialmente con el tamaño del ecosistema.
Por eso la discusión técnica sobre caducidad, testigos y Verkle no representa un debate académico, sino una carrera contra la inercia del crecimiento. Las redes que resuelvan esta ecuación técnica conservarán la capacidad de ser verificadas por cualquier participante. Las que no lo hagan se convertirán, con el tiempo, en bases de datos distribuidas gestionadas por unos pocos, independientemente del discurso sobre descentralización que mantengan.
