Un desafío que enfrenta Ethereum es que, por defecto, la expansión y complejidad de cualquier protocolo de blockchain tienden a aumentar con el tiempo. Esto ocurre en dos aspectos:
Datos históricos: Todas las transacciones realizadas y todas las cuentas creadas en cualquier momento de la historia deben ser almacenadas de forma permanente por todos los clientes y descargadas por cualquier nuevo cliente, lo que permite una sincronización completa con la red. Esto dará lugar a que la carga del cliente y el tiempo de sincronización aumenten continuamente con el tiempo, incluso si la capacidad de la cadena permanece constante.
Función del protocolo: agregar nuevas funciones es mucho más fácil que eliminar funciones antiguas, lo que lleva a un aumento de la complejidad del código con el tiempo.
Para que Ethereum pueda mantenerse a largo plazo, necesitamos ejercer una fuerte presión en contra de estas dos tendencias, reduciendo la complejidad y la expansión con el tiempo. Pero al mismo tiempo, necesitamos preservar una de las propiedades clave que hacen grande a la blockchain: la persistencia. Puedes colocar un NFT, una carta de amor en los datos de una transacción, o un contrato inteligente que contenga 1 millón de dólares en la cadena, entrar en una cueva durante diez años y salir para descubrir que todavía está allí, esperando que lo leas e interactúes. Para que las DApp puedan descentralizarse completamente y eliminar las claves de actualización con confianza, necesitan estar seguras de que sus dependencias no se actualizarán de manera que las perjudique, especialmente la L1 misma.
Si nos determinamos a encontrar un equilibrio entre estas dos necesidades y a minimizar o revertir la obsolescencia, la complejidad y el deterioro mientras mantenemos la continuidad, esto es absolutamente posible. Los organismos pueden lograrlo: aunque la mayoría de los organismos envejecen con el tiempo, unos pocos afortunados no lo hacen. Incluso los sistemas sociales pueden tener una vida útil muy larga. En algunos casos, Ethereum ya ha tenido éxito: el proof of work ha desaparecido, el código de operación SELFDESTRUCT ha desaparecido en su mayoría, y los nodos de la cadena de balizas han almacenado datos antiguos de hasta seis meses. Encontrar este camino para Ethereum de una manera más general y avanzar hacia un resultado final de estabilidad a largo plazo es el desafío definitivo de la escalabilidad a largo plazo de Ethereum, la sostenibilidad técnica e incluso la seguridad.
The Purge: objetivo principal.
Reducir los requisitos de almacenamiento del cliente al disminuir o eliminar la necesidad de que cada nodo almacene permanentemente todos los registros históricos e incluso el estado final.
Reducir la complejidad del protocolo eliminando funciones innecesarias.
Índice del artículo:
Historial de expiración
State expiry（状态到期）
Limpieza de características
Expiración de historial
¿Qué problema resuelve?
Hasta el momento de escribir este artículo, un nodo de Ethereum completamente sincronizado necesita aproximadamente 1.1 TB de espacio en disco para ejecutar el cliente, además de necesitar cientos de GB de espacio en disco para el cliente de consenso. La mayor parte de esto es historia: datos sobre bloques históricos, transacciones y recibos, la mayor parte de los cuales tienen varios años de antigüedad. Esto significa que, incluso si el límite de Gas no ha aumentado en absoluto, el tamaño del nodo seguirá aumentando cientos de GB cada año.
¿Qué es y cómo funciona?
Una característica clave que simplifica el problema del almacenamiento histórico es que, dado que cada bloque apunta al bloque anterior a través de un enlace hash (y otras estructuras), alcanzar un consenso sobre el actual es suficiente para alcanzar un consenso sobre el pasado. Siempre que la red alcance un consenso sobre el bloque más reciente, cualquier bloque histórico, transacción o estado (saldo de cuenta, número aleatorio, código, almacenamiento) puede ser proporcionado por cualquier participante individual junto con una prueba de Merkle, y esta prueba permite que cualquier otra persona verifique su corrección. El consenso es un modelo de confianza de N/2 de N, mientras que la historia es un modelo de confianza de N de N.
Esto nos ofrece muchas opciones sobre cómo almacenar el historial. Una elección natural es una red en la que cada nodo almacena solo una pequeña parte de los datos. Así es como ha funcionado la red de semillas durante décadas: aunque la red almacena y distribuye millones de archivos en total, cada participante almacena y distribuye solo unos pocos de esos archivos. Quizás en contra de la intuición, este enfoque ni siquiera necesariamente reduce la robustez de los datos. Si podemos construir una red de 100,000 nodos, donde cada nodo almacena aleatoriamente el 10% del historial, entonces cada dato se replicará 10,000 veces - exactamente el mismo factor de replicación que una red de 10,000 nodos, donde cada nodo almacena todo.
Hoy en día, Ethereum ha comenzado a deshacerse del modelo en el que todos los nodos almacenan permanentemente toda la historia. Los bloques de consenso (es decir, la parte relacionada con el consenso de prueba de participación) solo almacenan aproximadamente 6 meses. Blob solo se almacena durante aproximadamente 18 días. EIP-4444 tiene como objetivo introducir un período de almacenamiento de un año para los bloques históricos y los recibos. El objetivo a largo plazo es establecer un período unificado (posiblemente alrededor de 18 días), durante el cual cada nodo es responsable de almacenar todo, y luego establecer una red punto a punto compuesta por nodos de Ethereum, que almacene datos antiguos de manera distribuida.
Los códigos de borrado se pueden utilizar para aumentar la robustez, manteniendo al mismo tiempo el mismo factor de replicación. De hecho, Blob ya ha implementado códigos de borrado para soportar el muestreo de disponibilidad de datos. La solución más sencilla probablemente sea reutilizar estos códigos de borrado y también incluir los datos de ejecución y bloques de consenso en el blob.
¿qué conexiones hay con la investigación existente?
EIP-4444；
Torrents y EIP-4444；
Portal de red;
Portal Network y EIP-4444;
Almacenamiento y recuperación distribuida de objetos SSZ en Portal;
¿Cómo aumentar el límite de gas (Paradigm)?
¿Qué más necesita hacerse y qué se debe sopesar?
El trabajo principal restante incluye construir e integrar una solución distribuida concreta para almacenar el historial ------ al menos el historial de ejecución, pero finalmente también incluirá consenso y blob. La solución más sencilla es (i) simplemente introducir una biblioteca torrent existente, así como (ii) una solución nativa de Ethereum llamada Portal Network. Una vez que se introduzca cualquiera de estas, podremos activar el EIP-4444. El EIP-4444 en sí no requiere un hard fork, pero sí necesita una nueva versión del protocolo de red. Por lo tanto, es valioso habilitarlo para todos los clientes a la vez, de lo contrario existe el riesgo de que los clientes fallen al conectarse a otros nodos esperando descargar el historial completo, pero en realidad no lo obtienen.
Los principales compromisos implican cómo nos esforzamos por proporcionar datos históricos "antiguos". La solución más sencilla es dejar de almacenar historia antigua mañana y confiar en los nodos de archivo existentes y varios proveedores centralizados para la replicación. Esto es fácil, pero debilita la posición de Ethereum como un lugar de registro permanente. Un enfoque más difícil pero más seguro es construir e integrar primero una red torrent para almacenar el historial de manera distribuida. Aquí, "cuánto nos esforzamos" tiene dos dimensiones:
¿Cómo nos esforzamos para asegurar que el conjunto de nodos más grande realmente almacene todos los datos?
¿Qué tan profunda es la integración del almacenamiento histórico en el protocolo?
Un enfoque extremista para (1) implicaría la prueba de custodia: en realidad, exigir que cada validador de prueba de participación almacene un cierto porcentaje de registros históricos y verifique periódicamente de manera encriptada si lo están haciendo. Un enfoque más moderado sería establecer un estándar voluntario para el porcentaje de historial almacenado por cada cliente.
Para (2), la implementación básica solo involucra el trabajo que ya se ha completado hoy: el Portal ya ha almacenado un archivo ERA que contiene toda la historia de Ethereum. Una implementación más completa involucrará conectarlo realmente al proceso de sincronización, de modo que, si alguien desea sincronizar un nodo de almacenamiento de historial completo o un nodo de archivo, incluso si no hay otros nodos de archivo en línea, puede lograrlo mediante la sincronización directa desde la red del portal.
¿Cómo interactúa con otras partes de la hoja de ruta?
Si queremos que la operación o el inicio de los nodos sea extremadamente fácil, se puede decir que reducir los requisitos de almacenamiento histórico es más importante que la ausencia de estado: de los 1.1 TB necesarios para el nodo, aproximadamente 300 GB son estado, y los aproximadamente 800 GB restantes se han convertido en históricos. Solo al lograr la ausencia de estado y el EIP-4444 se podrá realizar la visión de ejecutar un nodo de Ethereum en un reloj inteligente y configurarlo en solo unos minutos.
Limitar el almacenamiento histórico también hace que la implementación de nodos de Ethereum más nuevos sea más viable, ya que solo admiten la última versión del protocolo, lo que las hace más sencillas. Por ejemplo, ahora se pueden eliminar de forma segura muchas líneas de código, ya que todos los espacios de almacenamiento vacíos creados durante el ataque DoS de 2016 han sido eliminados. Dado que la transición a la prueba de participación se ha convertido en historia, los clientes pueden eliminar de forma segura todo el código relacionado con la prueba de trabajo.
Expiración del estado
¿Qué problema resuelve?
Incluso si eliminamos la necesidad de que los clientes almacenen el historial, la demanda de almacenamiento del cliente seguirá creciendo, aproximadamente 50 GB por año, debido al crecimiento continuo del estado: saldos de cuentas y números aleatorios, código de contrato y almacenamiento de contratos. Los usuarios pueden pagar una tarifa única, lo que impone una carga a los clientes de Ethereum actuales y futuros.
El estado es más difícil de "expirar" que la historia, porque el EVM está fundamentalmente diseñado en torno a la suposición de que una vez que se crea un objeto de estado, siempre existirá y podrá ser leído en cualquier momento por cualquier transacción. Si introducimos la falta de estado, algunos creen que el problema tal vez no sea tan malo: solo las clases de constructores de bloques especializados necesitan almacenar realmente el estado, y todos los demás nodos (¡incluso aquellos que generan listas!) pueden funcionar sin estado. Sin embargo, hay una opinión de que no queremos depender demasiado de la falta de estado, y que al final podríamos querer hacer que el estado expire para mantener la descentralización de Ethereum.
¿Qué es y cómo funciona?
Hoy, cuando usted crea un nuevo objeto de estado (esto puede ocurrir de una de las siguientes tres maneras: (i) enviando ETH a una nueva cuenta, (ii) creando una nueva cuenta con código, (iii) configurando un slot de almacenamiento nunca tocado anteriormente), ese objeto de estado permanece en ese estado para siempre. En cambio, lo que queremos es que el objeto expire automáticamente con el tiempo. El desafío clave es lograr esto de una manera que cumpla con tres objetivos:
Eficiencia: no se requiere una gran cantidad de cálculos adicionales para ejecutar el proceso de vencimiento.
Facilidad de uso: Si alguien entra en una cueva durante cinco años y regresa, no debería perder el acceso a las posiciones de Ether, ERC20, NFT, CDP...
Amigabilidad para desarrolladores: los desarrolladores no tienen que cambiar a un modelo de pensamiento completamente desconocido. Además, las aplicaciones que actualmente están rígidas y no se actualizan deberían poder seguir funcionando normalmente.
No cumplir con estos objetivos hace que sea fácil resolver problemas. Por ejemplo, puede hacer que cada objeto de estado también almacene un contador de fecha de caducidad (que se puede extender quemando ETH, lo que puede ocurrir automáticamente al leer o escribir en cualquier momento) y tener un proceso que recorra el estado para eliminar los objetos de estado con fecha de caducidad. Sin embargo, esto introduce cálculos adicionales (incluso requisitos de almacenamiento), y definitivamente no puede satisfacer los requisitos de facilidad de uso. A los desarrolladores también les resulta difícil razonar sobre los casos límite en los que los valores almacenados a veces se reinician a cero. Si establece un temporizador de caducidad dentro del alcance del contrato, esto técnicamente facilitará la vida de los desarrolladores, pero complicará la economía: los desarrolladores deben considerar cómo "trasladar" el costo de almacenamiento continuo a los usuarios.
Estos son problemas que la comunidad de desarrollo central de Ethereum ha estado trabajando durante años, incluyendo propuestas como "alquiler de blockchain" y "renovación". Al final, combinamos las mejores partes de las propuestas y nos centramos en dos categorías de "soluciones conocidas como las menos malas":
Solución para el estado de expiración parcial
Sugerencias de vencimiento de estado basadas en el ciclo de dirección.
Expiración parcial del estado
Propuestas de estado que expiran parcialmente siguen los mismos principios. Dividimos el estado en bloques. Cada uno almacena permanentemente el "mapeo de nivel superior", donde los bloques pueden estar vacíos o no vacíos. Los datos en cada bloque solo se almacenarán si se ha accedido a esos datos recientemente. Hay un mecanismo de "resurrección" que se activa si ya no se almacenan.
 y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
12 me gusta
Recompensa
12
4
Republicar
Compartir
Comentar
0/400
HodlBeliever
· 08-10 09:55
Correr un contrato de cinco años costó 14 dólares, aún se puede ver.
Ver originalesResponder0
GasWaster
· 08-10 02:27
De lo burdo a lo fino, hemos avanzado.
Ver originalesResponder0
ChainSherlockGirl
· 08-10 02:23
¡Apresúrate a adelgazar, Vitalik Buterin! Tu casa está a punto de ser liquidado con tanto en la cadena.
Vitalik propuso la visión de Ethereum The Purge: Soltar la complejidad para lograr un desarrollo sostenible a largo plazo
Vitalik: El posible futuro de Ethereum, The Purge
Un desafío que enfrenta Ethereum es que, por defecto, la expansión y complejidad de cualquier protocolo de blockchain tienden a aumentar con el tiempo. Esto ocurre en dos aspectos:
Datos históricos: Todas las transacciones realizadas y todas las cuentas creadas en cualquier momento de la historia deben ser almacenadas de forma permanente por todos los clientes y descargadas por cualquier nuevo cliente, lo que permite una sincronización completa con la red. Esto dará lugar a que la carga del cliente y el tiempo de sincronización aumenten continuamente con el tiempo, incluso si la capacidad de la cadena permanece constante.
Función del protocolo: agregar nuevas funciones es mucho más fácil que eliminar funciones antiguas, lo que lleva a un aumento de la complejidad del código con el tiempo.
Para que Ethereum pueda mantenerse a largo plazo, necesitamos ejercer una fuerte presión en contra de estas dos tendencias, reduciendo la complejidad y la expansión con el tiempo. Pero al mismo tiempo, necesitamos preservar una de las propiedades clave que hacen grande a la blockchain: la persistencia. Puedes colocar un NFT, una carta de amor en los datos de una transacción, o un contrato inteligente que contenga 1 millón de dólares en la cadena, entrar en una cueva durante diez años y salir para descubrir que todavía está allí, esperando que lo leas e interactúes. Para que las DApp puedan descentralizarse completamente y eliminar las claves de actualización con confianza, necesitan estar seguras de que sus dependencias no se actualizarán de manera que las perjudique, especialmente la L1 misma.
Si nos determinamos a encontrar un equilibrio entre estas dos necesidades y a minimizar o revertir la obsolescencia, la complejidad y el deterioro mientras mantenemos la continuidad, esto es absolutamente posible. Los organismos pueden lograrlo: aunque la mayoría de los organismos envejecen con el tiempo, unos pocos afortunados no lo hacen. Incluso los sistemas sociales pueden tener una vida útil muy larga. En algunos casos, Ethereum ya ha tenido éxito: el proof of work ha desaparecido, el código de operación SELFDESTRUCT ha desaparecido en su mayoría, y los nodos de la cadena de balizas han almacenado datos antiguos de hasta seis meses. Encontrar este camino para Ethereum de una manera más general y avanzar hacia un resultado final de estabilidad a largo plazo es el desafío definitivo de la escalabilidad a largo plazo de Ethereum, la sostenibilidad técnica e incluso la seguridad.
The Purge: objetivo principal.
Reducir los requisitos de almacenamiento del cliente al disminuir o eliminar la necesidad de que cada nodo almacene permanentemente todos los registros históricos e incluso el estado final.
Reducir la complejidad del protocolo eliminando funciones innecesarias.
Índice del artículo:
Historial de expiración
State expiry（状态到期）
Limpieza de características
Expiración de historial
¿Qué problema resuelve?
Hasta el momento de escribir este artículo, un nodo de Ethereum completamente sincronizado necesita aproximadamente 1.1 TB de espacio en disco para ejecutar el cliente, además de necesitar cientos de GB de espacio en disco para el cliente de consenso. La mayor parte de esto es historia: datos sobre bloques históricos, transacciones y recibos, la mayor parte de los cuales tienen varios años de antigüedad. Esto significa que, incluso si el límite de Gas no ha aumentado en absoluto, el tamaño del nodo seguirá aumentando cientos de GB cada año.
¿Qué es y cómo funciona?
Una característica clave que simplifica el problema del almacenamiento histórico es que, dado que cada bloque apunta al bloque anterior a través de un enlace hash (y otras estructuras), alcanzar un consenso sobre el actual es suficiente para alcanzar un consenso sobre el pasado. Siempre que la red alcance un consenso sobre el bloque más reciente, cualquier bloque histórico, transacción o estado (saldo de cuenta, número aleatorio, código, almacenamiento) puede ser proporcionado por cualquier participante individual junto con una prueba de Merkle, y esta prueba permite que cualquier otra persona verifique su corrección. El consenso es un modelo de confianza de N/2 de N, mientras que la historia es un modelo de confianza de N de N.
Esto nos ofrece muchas opciones sobre cómo almacenar el historial. Una elección natural es una red en la que cada nodo almacena solo una pequeña parte de los datos. Así es como ha funcionado la red de semillas durante décadas: aunque la red almacena y distribuye millones de archivos en total, cada participante almacena y distribuye solo unos pocos de esos archivos. Quizás en contra de la intuición, este enfoque ni siquiera necesariamente reduce la robustez de los datos. Si podemos construir una red de 100,000 nodos, donde cada nodo almacena aleatoriamente el 10% del historial, entonces cada dato se replicará 10,000 veces - exactamente el mismo factor de replicación que una red de 10,000 nodos, donde cada nodo almacena todo.
Hoy en día, Ethereum ha comenzado a deshacerse del modelo en el que todos los nodos almacenan permanentemente toda la historia. Los bloques de consenso (es decir, la parte relacionada con el consenso de prueba de participación) solo almacenan aproximadamente 6 meses. Blob solo se almacena durante aproximadamente 18 días. EIP-4444 tiene como objetivo introducir un período de almacenamiento de un año para los bloques históricos y los recibos. El objetivo a largo plazo es establecer un período unificado (posiblemente alrededor de 18 días), durante el cual cada nodo es responsable de almacenar todo, y luego establecer una red punto a punto compuesta por nodos de Ethereum, que almacene datos antiguos de manera distribuida.
Los códigos de borrado se pueden utilizar para aumentar la robustez, manteniendo al mismo tiempo el mismo factor de replicación. De hecho, Blob ya ha implementado códigos de borrado para soportar el muestreo de disponibilidad de datos. La solución más sencilla probablemente sea reutilizar estos códigos de borrado y también incluir los datos de ejecución y bloques de consenso en el blob.
¿qué conexiones hay con la investigación existente?
EIP-4444；
Torrents y EIP-4444；
Portal de red;
Portal Network y EIP-4444;
Almacenamiento y recuperación distribuida de objetos SSZ en Portal;
¿Cómo aumentar el límite de gas (Paradigm)?
¿Qué más necesita hacerse y qué se debe sopesar?
El trabajo principal restante incluye construir e integrar una solución distribuida concreta para almacenar el historial ------ al menos el historial de ejecución, pero finalmente también incluirá consenso y blob. La solución más sencilla es (i) simplemente introducir una biblioteca torrent existente, así como (ii) una solución nativa de Ethereum llamada Portal Network. Una vez que se introduzca cualquiera de estas, podremos activar el EIP-4444. El EIP-4444 en sí no requiere un hard fork, pero sí necesita una nueva versión del protocolo de red. Por lo tanto, es valioso habilitarlo para todos los clientes a la vez, de lo contrario existe el riesgo de que los clientes fallen al conectarse a otros nodos esperando descargar el historial completo, pero en realidad no lo obtienen.
Los principales compromisos implican cómo nos esforzamos por proporcionar datos históricos "antiguos". La solución más sencilla es dejar de almacenar historia antigua mañana y confiar en los nodos de archivo existentes y varios proveedores centralizados para la replicación. Esto es fácil, pero debilita la posición de Ethereum como un lugar de registro permanente. Un enfoque más difícil pero más seguro es construir e integrar primero una red torrent para almacenar el historial de manera distribuida. Aquí, "cuánto nos esforzamos" tiene dos dimensiones:
¿Cómo nos esforzamos para asegurar que el conjunto de nodos más grande realmente almacene todos los datos?
¿Qué tan profunda es la integración del almacenamiento histórico en el protocolo?
Un enfoque extremista para (1) implicaría la prueba de custodia: en realidad, exigir que cada validador de prueba de participación almacene un cierto porcentaje de registros históricos y verifique periódicamente de manera encriptada si lo están haciendo. Un enfoque más moderado sería establecer un estándar voluntario para el porcentaje de historial almacenado por cada cliente.
Para (2), la implementación básica solo involucra el trabajo que ya se ha completado hoy: el Portal ya ha almacenado un archivo ERA que contiene toda la historia de Ethereum. Una implementación más completa involucrará conectarlo realmente al proceso de sincronización, de modo que, si alguien desea sincronizar un nodo de almacenamiento de historial completo o un nodo de archivo, incluso si no hay otros nodos de archivo en línea, puede lograrlo mediante la sincronización directa desde la red del portal.
¿Cómo interactúa con otras partes de la hoja de ruta?
Si queremos que la operación o el inicio de los nodos sea extremadamente fácil, se puede decir que reducir los requisitos de almacenamiento histórico es más importante que la ausencia de estado: de los 1.1 TB necesarios para el nodo, aproximadamente 300 GB son estado, y los aproximadamente 800 GB restantes se han convertido en históricos. Solo al lograr la ausencia de estado y el EIP-4444 se podrá realizar la visión de ejecutar un nodo de Ethereum en un reloj inteligente y configurarlo en solo unos minutos.
Limitar el almacenamiento histórico también hace que la implementación de nodos de Ethereum más nuevos sea más viable, ya que solo admiten la última versión del protocolo, lo que las hace más sencillas. Por ejemplo, ahora se pueden eliminar de forma segura muchas líneas de código, ya que todos los espacios de almacenamiento vacíos creados durante el ataque DoS de 2016 han sido eliminados. Dado que la transición a la prueba de participación se ha convertido en historia, los clientes pueden eliminar de forma segura todo el código relacionado con la prueba de trabajo.
Expiración del estado
¿Qué problema resuelve?
Incluso si eliminamos la necesidad de que los clientes almacenen el historial, la demanda de almacenamiento del cliente seguirá creciendo, aproximadamente 50 GB por año, debido al crecimiento continuo del estado: saldos de cuentas y números aleatorios, código de contrato y almacenamiento de contratos. Los usuarios pueden pagar una tarifa única, lo que impone una carga a los clientes de Ethereum actuales y futuros.
El estado es más difícil de "expirar" que la historia, porque el EVM está fundamentalmente diseñado en torno a la suposición de que una vez que se crea un objeto de estado, siempre existirá y podrá ser leído en cualquier momento por cualquier transacción. Si introducimos la falta de estado, algunos creen que el problema tal vez no sea tan malo: solo las clases de constructores de bloques especializados necesitan almacenar realmente el estado, y todos los demás nodos (¡incluso aquellos que generan listas!) pueden funcionar sin estado. Sin embargo, hay una opinión de que no queremos depender demasiado de la falta de estado, y que al final podríamos querer hacer que el estado expire para mantener la descentralización de Ethereum.
¿Qué es y cómo funciona?
Hoy, cuando usted crea un nuevo objeto de estado (esto puede ocurrir de una de las siguientes tres maneras: (i) enviando ETH a una nueva cuenta, (ii) creando una nueva cuenta con código, (iii) configurando un slot de almacenamiento nunca tocado anteriormente), ese objeto de estado permanece en ese estado para siempre. En cambio, lo que queremos es que el objeto expire automáticamente con el tiempo. El desafío clave es lograr esto de una manera que cumpla con tres objetivos:
Eficiencia: no se requiere una gran cantidad de cálculos adicionales para ejecutar el proceso de vencimiento.
Facilidad de uso: Si alguien entra en una cueva durante cinco años y regresa, no debería perder el acceso a las posiciones de Ether, ERC20, NFT, CDP...
Amigabilidad para desarrolladores: los desarrolladores no tienen que cambiar a un modelo de pensamiento completamente desconocido. Además, las aplicaciones que actualmente están rígidas y no se actualizan deberían poder seguir funcionando normalmente.
No cumplir con estos objetivos hace que sea fácil resolver problemas. Por ejemplo, puede hacer que cada objeto de estado también almacene un contador de fecha de caducidad (que se puede extender quemando ETH, lo que puede ocurrir automáticamente al leer o escribir en cualquier momento) y tener un proceso que recorra el estado para eliminar los objetos de estado con fecha de caducidad. Sin embargo, esto introduce cálculos adicionales (incluso requisitos de almacenamiento), y definitivamente no puede satisfacer los requisitos de facilidad de uso. A los desarrolladores también les resulta difícil razonar sobre los casos límite en los que los valores almacenados a veces se reinician a cero. Si establece un temporizador de caducidad dentro del alcance del contrato, esto técnicamente facilitará la vida de los desarrolladores, pero complicará la economía: los desarrolladores deben considerar cómo "trasladar" el costo de almacenamiento continuo a los usuarios.
Estos son problemas que la comunidad de desarrollo central de Ethereum ha estado trabajando durante años, incluyendo propuestas como "alquiler de blockchain" y "renovación". Al final, combinamos las mejores partes de las propuestas y nos centramos en dos categorías de "soluciones conocidas como las menos malas":
Expiración parcial del estado
Propuestas de estado que expiran parcialmente siguen los mismos principios. Dividimos el estado en bloques. Cada uno almacena permanentemente el "mapeo de nivel superior", donde los bloques pueden estar vacíos o no vacíos. Los datos en cada bloque solo se almacenarán si se ha accedido a esos datos recientemente. Hay un mecanismo de "resurrección" que se activa si ya no se almacenan.
![Vitalik: El posible futuro de Ethereum, The Purge](https://