{"id":165843,"date":"2026-08-04T04:15:34","date_gmt":"2026-08-04T04:15:34","guid":{"rendered":"https:\/\/crypto-economy.com\/es\/?p=165843"},"modified":"2026-08-04T04:15:36","modified_gmt":"2026-08-04T04:15:36","slug":"state-expiry-en-ethereum","status":"publish","type":"post","link":"https:\/\/crypto-economy.com\/es\/state-expiry-en-ethereum\/","title":{"rendered":"State expiry en Ethereum: \u00bfEl fin del almacenamiento perpetuo o el principio de una red verificable para siempre?"},"content":{"rendered":"

El modelo de almacenamiento perpetuo<\/a> que adoptaron las primeras blockchains contiene una contradicci\u00f3n que se vuelve m\u00e1s evidente con cada ciclo de adopci\u00f3n. Exigir que cada nodo validador conserve la totalidad del estado \u2014el conjunto de saldos, nonces y almacenamiento de contratos accesible en el bloque m\u00e1s reciente\u2014 sin ning\u00fan mecanismo de vencimiento equivale a imponer una carga asint\u00f3tica sobre los operadores.<\/span><\/p>\n

<\/p>\n

Con el tiempo, esa carga transforma la verificaci\u00f3n independiente en un privilegio de infraestructura. <\/span>La caducidad del estado no es una optimizaci\u00f3n cosm\u00e9tica: constituye la respuesta t\u00e9cnica a la pregunta de c\u00f3mo un protocolo permissionless puede preservar la verificabilidad cuando el uso se mide en d\u00e9cadas.<\/b><\/p>\n

Para entender la magnitud del problema conviene separar dos componentes que suelen confundirse. El <\/span>historial de transacciones<\/b> es un registro secuencial que puede podarse, archivarse o distribuirse sin afectar la validaci\u00f3n del presente.<\/span><\/p>\n

El <\/span>estado es la fotograf\u00eda actualizada de todo aquello que una transacci\u00f3n puede leer o modificar directamente: cada cuenta, cada slot de almacenamiento de cada contrato, cada entrada en un mapa.<\/span><\/p>\n

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\u00edo, <\/span>el estado impone costos de hardware que crecen de forma mon\u00f3tona.<\/b><\/p>\n

La <\/span>expansi\u00f3n inercial del estado<\/b> es consecuencia directa de la permanencia de los datos. Un nuevo usuario, un nuevo token o una nueva posici\u00f3n en un protocolo DeFi<\/a> a\u00f1aden 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 \u00e1rbol de estado subyacente.<\/span><\/p>\n

La experiencia de Ethereum resulta ilustrativa: <\/span>el estado ha pasado de unos pocos gigabytes en 2016 a varios cientos de gigabytes en la actualidad.<\/b> Esa tendencia incrementa los requisitos de almacenamiento, eleva los tiempos de sincronizaci\u00f3n y, sobre todo, <\/span>reduce el n\u00famero de actores capaces de operar un nodo completo de validaci\u00f3n.<\/b><\/p>\n

\"blockchain\"<\/p>\n

La concentraci\u00f3n de nodos en centros de datos y proveedores de nube representa la consecuencia m\u00e1s lesiva. Cuando los costos de hardware excluyen a los participantes con equipos de consumo, el principio de <\/span>\u201cno conf\u00edes, verifica\u201d<\/b> se degrada hacia una arquitectura donde la mayor\u00eda de los usuarios delega la verificaci\u00f3n en infraestructura ajena, a menudo centralizada en pocos proveedores de RPC.<\/span><\/p>\n

La <\/span>presi\u00f3n centralizadora inducida por el estado<\/b> opera de manera silenciosa, sin requerir cambios de protocolo ni actores maliciosos. Basta con que el costo incremental expulse a los validadores dom\u00e9sticos para que la capa de consenso repose sobre un conjunto cada vez m\u00e1s homog\u00e9neo de entidades.<\/span><\/p>\n

Ante este diagn\u00f3stico, eliminar sin m\u00e1s el estado antiguo no constituye una opci\u00f3n viable. Si un nodo descarta la informaci\u00f3n correspondiente a una cuenta que lleva a\u00f1os inactiva, se vuelve incapaz de validar una transacci\u00f3n futura que involucre esa cuenta. Desconocer el saldo y el nonce impide discernir si la operaci\u00f3n es leg\u00edtima o si constituye un intento de doble gasto.<\/span><\/p>\n

Recalcular el estado desde el bloque g\u00e9nesis para restaurar una sola cuenta resulta computacionalmente prohibitivo. La clave t\u00e9cnica reside, por tanto, en transferir la carga de almacenamiento desde el consenso hacia el usuario, sin sacrificar la capacidad de verificaci\u00f3n de los validadores. <\/span>Eso es lo que persigue la caducidad del estado.<\/b><\/p>\n

La <\/span>caducidad del estado<\/b> define una frontera temporal: los datos que no han sido accedidos durante un per\u00edodo preestablecido pasan de formar parte del estado activo que los validadores deben mantener a una capa de almacenamiento secundaria.<\/span><\/p>\n

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 <\/span>estructuras de datos criptogr\u00e1ficos<\/b> que permiten probar la pertenencia de un valor al estado sin necesidad de almacenar el \u00e1rbol completo.<\/span><\/p>\n

Los <\/span>\u00e1rboles de Verkle<\/b> constituyen el habilitador fundamental de ese cambio. A diferencia de los \u00e1rboles de Merkle-Patricia actuales, los compromisos vectoriales basados en Verkle producen pruebas de tama\u00f1o reducido \u2014del orden de unos pocos cientos de bytes\u2014 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\u00f3n.<\/span><\/p>\n

Cuando un usuario desea reactivar una cuenta dormida, adjunta un <\/span>testigo (witness)<\/b> con la prueba criptogr\u00e1fica del \u00faltimo estado v\u00e1lido. Los validadores verifican el testigo sin haber almacenado el dato expirado y, tras la comprobaci\u00f3n, incorporan la cuenta al estado activo. <\/span>La red no conserva el estado perpetuo; conserva la capacidad de validar su resurrecci\u00f3n bajo demanda.<\/b><\/p>\n

El plan de trabajo descrito por los investigadores de Ethereum introduce<\/a>, adem\u00e1s, una modificaci\u00f3n en el formato de las direcciones para incluir un <\/span>marcador de \u00e9poca<\/b>. Este marcador permite determinar sin ambig\u00fcedad si una cuenta pertenece a un per\u00edodo ya expirado y qu\u00e9 ra\u00edz de Verkle<\/a> debe utilizarse para verificar el testigo.<\/span><\/p>\n

El mecanismo de <\/span>expiraci\u00f3n por \u00e9poca<\/b> segmenta el estado en funci\u00f3n del \u00faltimo acceso y proporciona un camino claro para que el software de billetera gestione testigos de manera autom\u00e1tica. El usuario no necesita comprender la infraestructura subyacente; la billetera almacena o recupera el testigo cuando corresponde.<\/span><\/p>\n

\"blockchain\"<\/p>\n

La combinaci\u00f3n de <\/span>validaci\u00f3n sin estado<\/b> 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\u00edan ning\u00fan estado y recibir\u00edan testigos con cada transacci\u00f3n.<\/span><\/p>\n

La caducidad del estado puede entenderse como una implementaci\u00f3n h\u00edbrida: los validadores mantienen el <\/span>estado caliente<\/b> \u2014el que se modifica con frecuencia\u2014 y exigen testigos solo para los datos que han superado el umbral de inactividad. El resultado es un <\/span>tama\u00f1o acotado del estado activo<\/b> que puede fijarse en un valor compatible con discos de consumo, por ejemplo entre 20 y 50 GB. Con ese l\u00edmite, operar un nodo validador completo sigue siendo factible para cualquier persona con una conexi\u00f3n de banda ancha est\u00e1ndar y un ordenador port\u00e1til.<\/span><\/p>\n

Los desaf\u00edos que plantea este modelo no son triviales y se concentran en tres \u00e1reas: <\/span>disponibilidad de testigos, experiencia de usuario y dependencia de contratos inactivos.<\/b> La <\/span>disponibilidad de testigos<\/b> requiere que existan nodos de archivo o proveedores de estado que conserven los datos expirados y generen las pruebas bajo demanda.<\/span><\/p>\n

Si esos proveedores se consolidan en un n\u00famero reducido de entidades, aparece un nuevo vector de centralizaci\u00f3n, aunque de naturaleza distinta: no afecta a la validaci\u00f3n del consenso, pero s\u00ed a la capacidad de los usuarios para recuperar sus cuentas de forma aut\u00f3noma. Mitigar ese riesgo exige <\/span>protocolos de distribuci\u00f3n de testigos<\/b> que permitan a las billeteras almacenar su propia prueba en el momento de la expiraci\u00f3n o replicarla en redes descentralizadas de almacenamiento.<\/span><\/p>\n

La <\/span>experiencia de usuario<\/b> se modifica porque el titular de una cuenta que permanece inactiva durante a\u00f1os debe conservar o poder recuperar el testigo correspondiente. Las billeteras deber\u00e1n incorporar <\/span>flujos de resurrecci\u00f3n autom\u00e1tica<\/b> que abstraigan esa complejidad. Un usuario que recibe un activo en una direcci\u00f3n dormida y desconoce el mecanismo de testigos podr\u00eda encontrar que la transacci\u00f3n requiere un paso adicional de reactivaci\u00f3n.\u00a0<\/span><\/p>\n

La evoluci\u00f3n de los est\u00e1ndares de billetera y la comunicaci\u00f3n con los exchanges resultan imprescindibles para que la caducidad no se traduzca en fricci\u00f3n operativa.<\/span><\/p>\n

\"blockchain<\/p>\n

El tercer desaf\u00edo ata\u00f1e a los <\/span>contratos inteligentes de baja frecuencia de uso pero alta relevancia sist\u00e9mica<\/b>. Un contrato de gobernanza que solo se invoca durante situaciones excepcionales podr\u00eda expirar entre votaciones. El costo de resurrecci\u00f3n \u2014tanto en gas como en provisi\u00f3n de testigos\u2014 debe ser lo suficientemente bajo para que la reactivaci\u00f3n no introduzca barreras econ\u00f3micas.<\/span><\/p>\n

Los dise\u00f1adores del protocolo estudian mecanismos que permitan a los propios contratos pagar por su permanencia en el estado activo o delegar en terceros la renovaci\u00f3n peri\u00f3dica mediante transacciones de <\/span>\u201ckeep-alive\u201d<\/b> econ\u00f3micamente racionales.<\/span><\/p>\n

Las alternativas previas a la caducidad del estado basada en testigos, como el <\/span>alquiler de estado<\/b>, intentaron abordar la expansi\u00f3n mediante pagos recurrentes por el almacenamiento. Ese camino gener\u00f3 rechazo por los efectos sobre la propiedad: la posibilidad de perder un NFT o un saldo por no abonar una tasa peri\u00f3dica contradice expectativas fundamentales de los usuarios.<\/span><\/p>\n

La caducidad con testigos invierte la l\u00f3gica: el dato no se pierde, pero su custodia se transfiere al interesado. <\/span>El protocolo deja de garantizar el almacenamiento perpetuo y pasa a garantizar la verificabilidad perpetua.<\/b> Esa distinci\u00f3n resulta central para comprender el cambio de paradigma.<\/span><\/p>\n

La implementaci\u00f3n de la <\/span>caducidad del estado<\/b> requiere modificar la capa de ejecuci\u00f3n, actualizar las estructuras de datos del estado global y coordinar una transici\u00f3n en el formato de direcciones. El calendario t\u00e9cnico de Ethereum sit\u00faa la <\/span>migraci\u00f3n a \u00e1rboles de Verkle<\/b> como paso previo necesario, seguido por la introducci\u00f3n progresiva de la expiraci\u00f3n por \u00e9poca. La comunidad de desarrolladores de clientes y los equipos de investigaci\u00f3n trabajan en prototipos que permitan evaluar los costos de resurrecci\u00f3n y la sobrecarga de ancho de banda asociada a la inclusi\u00f3n de testigos en las transacciones.<\/span><\/p>\n

Los resultados preliminares indican que el incremento en el tama\u00f1o de los bloques por la inclusi\u00f3n de testigos resulta manejable, en especial si se aplican <\/span>esquemas de agregaci\u00f3n de pruebas.<\/b><\/p>\n

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 <\/span>preservaci\u00f3n de la descentralizaci\u00f3n de la validaci\u00f3n<\/b><\/a> exige en todas ellas un compromiso expl\u00edcito con la acotaci\u00f3n del estado.<\/span><\/p>\n

Los dise\u00f1os que postergan esta discusi\u00f3n mientras se enfocan exclusivamente en el aumento del rendimiento mediante <\/span>ejecuci\u00f3n paralela o disponibilidad de datos externa<\/b> est\u00e1n acumulando una deuda t\u00e9cnica que se manifestar\u00e1 cuando el estado activo supere las capacidades del hardware accesible para el operador independiente.<\/span><\/p>\n

La caducidad del estado constituye, en \u00faltima instancia, una decisi\u00f3n de arquitectura sobre <\/span>qui\u00e9n soporta el costo del paso del tiempo en una red descentralizada.<\/b> Si ese costo se socializa entre todos los validadores, el resultado es una presi\u00f3n constante hacia la centralizaci\u00f3n de la infraestructura.<\/span><\/p>\n

Si, por el contrario, se asigna a quien genera la demanda de permanencia, el sistema puede fijar un l\u00edmite superior al estado activo y mantener la verificabilidad en equipos de bajo costo. <\/span>La tecnolog\u00eda de testigos y \u00e1rboles de Verkle ofrece por primera vez una v\u00eda para implementar esa asignaci\u00f3n sin sacrificar la capacidad de validaci\u00f3n sin confianza.<\/b><\/p>\n

Un protocolo que no incorpora <\/span>caducidad del estado<\/b> puede funcionar durante a\u00f1os sin signos evidentes de deterioro, pero acumula una fragilidad estructural que se vuelve irreversible cuando los operadores dom\u00e9sticos abandonan la red. La historia de los sistemas distribuidos muestra que la complejidad de la coordinaci\u00f3n para introducir cambios de este calibre crece exponencialmente con el tama\u00f1o del ecosistema.<\/span><\/p>\n

Por eso la discusi\u00f3n t\u00e9cnica sobre <\/span>caducidad, testigos y Verkle<\/b> no representa un debate acad\u00e9mico, sino una carrera contra la inercia del crecimiento. Las redes que resuelvan esta ecuaci\u00f3n t\u00e9cnica conservar\u00e1n la capacidad de ser verificadas por cualquier participante. Las que no lo hagan se convertir\u00e1n, con el tiempo, en <\/span>bases de datos distribuidas gestionadas por unos pocos<\/b>, independientemente del discurso sobre descentralizaci\u00f3n que mantengan.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

El modelo de almacenamiento perpetuo que adoptaron las primeras blockchains contiene una contradicci\u00f3n que se vuelve m\u00e1s evidente con cada ciclo de adopci\u00f3n. Exigir que cada nodo validador conserve la totalidad del estado \u2014el conjunto de saldos, nonces y almacenamiento de contratos accesible en el bloque m\u00e1s reciente\u2014 sin ning\u00fan mecanismo de vencimiento equivale a … <\/p>\n

Leer m\u00e1s<\/a><\/p>\n","protected":false},"author":53,"featured_media":165844,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"","footnotes":""},"categories":[925],"tags":[9408,9407,9406],"class_list":["post-165843","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-opinion","tag-almacenamiento-perpetuo","tag-ethereum-network","tag-state-expiry"],"_links":{"self":[{"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/posts\/165843","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/users\/53"}],"replies":[{"embeddable":true,"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/comments?post=165843"}],"version-history":[{"count":1,"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/posts\/165843\/revisions"}],"predecessor-version":[{"id":165845,"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/posts\/165843\/revisions\/165845"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/media\/165844"}],"wp:attachment":[{"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/media?parent=165843"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/categories?post=165843"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/crypto-economy.com\/es\/wp-json\/wp\/v2\/tags?post=165843"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}