Uno de los desafíos que enfrenta Ethereum es que, por defecto, la expansión y complejidad de cualquier protocolo de blockchain tiende a aumentar con el tiempo. Esto ocurre en dos lugares:
Datos históricos: Cualquier transacción realizada y cualquier cuenta creada en cualquier momento de la historia debe ser almacenada permanentemente por todos los clientes y descargada por cualquier nuevo cliente, de modo que se sincronice completamente con la red. Esto resultará en una carga para los clientes y un aumento del tiempo de sincronización a medida que pasa 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 mantener su sostenibilidad a largo plazo, necesitamos ejercer una fuerte presión de retroceso sobre 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 que la blockchain sea grandiosa: la persistencia. Puedes poner un NFT, una carta de amor en los datos de una llamada de transacción, o un contrato inteligente que contenga un millón de dólares en la cadena, entrar en una cueva durante diez años y salir para descubrir que aún está allí, esperando que lo leas e interactúes. Para que DApp pueda descentralizarse completamente y eliminar las claves de actualización con confianza, necesitan estar seguros de que sus dependencias no se actualizarán de una manera que las perjudique - especialmente L1 en sí mismo.
Si nos comprometemos a equilibrar estas dos demandas y a minimizar o revertir la obsolescencia, la complejidad y el deterioro al mismo tiempo que mantenemos la continuidad, es absolutamente posible. Los organismos pueden lograr esto: aunque la mayoría de los organismos envejecen con el tiempo, algunos afortunados no lo hacen. Incluso los sistemas sociales pueden tener una vida útil muy larga. En ciertos casos, Ethereum ya ha tenido éxito: la prueba de trabajo ha desaparecido, el código de operación SELFDESTRUCT ha desaparecido en su mayor parte, y los nodos de la cadena de referencia han almacenado datos antiguos por un máximo de seis meses. Encontrar este camino para Ethereum de una manera más general y avanzar hacia un resultado final estable a largo plazo es el desafío definitivo para la escalabilidad a largo plazo de Ethereum, la sostenibilidad técnica e incluso la seguridad.
The Purge: Objetivos principales.
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
Estado de expiración（状态到期）
Limpieza de características
Expiración de historial
¿Qué problema resuelve?
Hasta el momento de redactar 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 varios cientos de GB de espacio en disco para el cliente de consenso. La mayor parte de esto es histórico: datos sobre bloques históricos, transacciones y recibos, la mayoría de los cuales tienen varios años de antigüedad. Esto significa que incluso si el límite de Gas no aumenta en absoluto, el tamaño del nodo seguirá aumentando cientos de GB cada año.
¿Qué es eso y cómo funciona?
Una característica clave de simplificación del problema de almacenamiento histórico es que, dado que cada bloque apunta al bloque anterior a través de enlaces hash (y otras estructuras), es suficiente alcanzar consenso sobre el actual para alcanzar consenso sobre el histórico. Mientras la red alcance 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 N/2-of-N, mientras que la historia es un modelo de confianza N-of-N.
Esto nos ofrece muchas opciones sobre cómo almacenar el historial. Una elección natural es una red donde cada nodo solo almacena una pequeña parte de los datos. Así es como han funcionado las redes de semillas durante décadas: aunque la red almacena y distribuye millones de archivos en total, cada participante solo almacena y distribuye unos pocos de ellos. Quizás contrariamente a la intuición, este enfoque ni siquiera necesariamente reduce la robustez de los datos. Si podemos construir una red con 100,000 nodos, donde cada nodo almacena aleatoriamente el 10% del historial, entonces cada dato se copiará 10,000 veces - lo que es exactamente el mismo factor de copia que una red de 10,000 nodos, donde cada nodo almacena todo.
Hoy en día, Ethereum ha comenzado a alejarse 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. Los blobs solo almacenan 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 de 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 usar 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 colocar los datos de ejecución y consenso en el blob.
¿Qué conexiones tiene con la investigación existente?
EIP-4444；
Torrents y EIP-4444；
Portal de red;
Red de puertas 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 se necesita hacer, qué se debe considerar?
El trabajo principal restante incluye construir e integrar una solución distribuida específica para almacenar el historial ------ al menos el historial de ejecución, pero eventualmente también incluirá el consenso y los blobs. La solución más sencilla es (i) simplemente introducir bibliotecas torrent existentes, así como (ii) una solución nativa de Ethereum llamada Portal Network. Una vez que introduzcamos cualquiera de estas, podremos abrir EIP-4444. EIP-4444 en sí no requiere un hard fork, pero sí necesita una nueva versión del protocolo de red. Por lo tanto, vale la pena habilitarlo para todos los clientes al mismo tiempo, de lo contrario, existe el riesgo de que los clientes fallen debido a que se conectan a otros nodos esperando descargar el historial completo, pero en realidad no lo obtienen.
Las principales compensaciones implican cómo nos esforzamos por proporcionar datos históricos "antiguos". La solución más simple es dejar de almacenar datos históricos antiguos mañana y depender de los nodos archivados 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 los registros de manera distribuida. Aquí, "cuánto esfuerzo ponemos" 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 extremadamente paranoico para (1) implicaría la prueba de custodia: de hecho, requeriría que cada validador de prueba de participación almacenara un porcentaje determinado del historial y lo verificara de forma criptográfica regularmente para asegurarse de que así lo hicieran. 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 implica el trabajo que ya se ha completado hoy: el Portal ya ha almacenado archivos ERA que contienen toda la historia de Ethereum. Una implementación más completa implicará 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, pueden hacerlo a través de 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 ejecución o el inicio de nodos sea extremadamente fácil, entonces reducir la demanda de almacenamiento histórico podría considerarse más importante que la falta de estado: de los 1.1 TB necesarios para el nodo, aproximadamente 300 GB son estado, y el resto, aproximadamente 800 GB, se ha convertido en histórico. Solo logrando la falta de estado y el EIP-4444 se puede realizar la visión de ejecutar un nodo de Ethereum en un reloj inteligente y configurarlo en solo unos minutos.
La limitación del almacenamiento histórico también hace que los nodos de Ethereum más recientes sean más viables, ya que solo admiten la versión más reciente del protocolo, lo que los hace más simples. 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 el cliente almacene el historial, la demanda de almacenamiento del cliente seguirá creciendo, aproximadamente 50 GB cada 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 generará una carga para los clientes de Ethereum, tanto ahora como en el futuro.
El estado es más difícil de "expirar" que la historia, porque el EVM está diseñado fundamentalmente en torno a la suposición de que una vez que se crea un objeto de estado, siempre existirá y podrá ser leído por cualquier transacción en cualquier momento. Si introducimos la falta de estado, algunos piensan que este problema tal vez no sea tan malo: solo las clases de constructores de bloques dedicadas necesitan almacenar realmente el estado, mientras que todos los demás nodos (¡incluso aquellos que generan listas!) pueden funcionar sin estado. Sin embargo, hay una opinión que sostiene que no queremos depender demasiado de la falta de estado; 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 crea un nuevo objeto de estado (lo que 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 que no se ha 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 hacerlo de una manera que logre tres objetivos:
Eficiencia: no se necesita 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 sus posiciones de Ether, ERC20, NFT y CDP...
Amigabilidad para los 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 satisfacer estos objetivos hace que resolver problemas sea muy sencillo. Por ejemplo, puede hacer que cada objeto de estado también almacene un contador de fecha de expiración (que se puede extender quemando ETH, lo cual podría ocurrir automáticamente en cualquier momento al leer o escribir), y tener un proceso que recorra el estado para eliminar los objetos de estado con fecha de expiración. Sin embargo, esto introduce cálculos adicionales (incluso requerimientos de almacenamiento), y definitivamente no puede satisfacer los requisitos de facilidad de uso. A los desarrolladores también les resulta difícil razonar sobre las situaciones límite en las que los valores almacenados a veces se restablecen a cero. Si establece un temporizador de expiración dentro del contrato, esto técnicamente facilitaría la vida a los desarrolladores, pero complicaría 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 tratando de resolver durante años, incluyendo propuestas como "alquiler de blockchain" y "renovación". Al final, combinamos las mejores partes de las propuestas y nos concentramos en dos categorías de "las soluciones conocidas menos malas":
Solución para el estado de parte caducado
Sugerencias sobre la expiración del estado basado en el ciclo de direcciones.
Expiración parcial del estado
Algunas propuestas de estado de vencimiento siguen los mismos principios. Dividimos el estado en bloques. Todos almacenan permanentemente el "mapeo superior".
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) 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.
13 me gusta
Recompensa
13
7
Republicar
Compartir
Comentar
0/400
Hash_Bandit
· 08-06 19:58
he visto esto antes... como en los días de la minería cuando optimizamos la sincronización de nodos. eth necesita más eficiencia estilo hashrate, para ser honesto.
Ver originalesResponder0
ILCollector
· 08-04 07:11
Se recomienda empaquetar los datos con L2
Ver originalesResponder0
TokenomicsTrapper
· 08-03 21:09
llamé a este problema de exceso hace meses... clásica espiral de muerte por deuda técnica en camino
Ver originalesResponder0
HackerWhoCares
· 08-03 21:09
El almacenamiento en expansión sigue siendo un gran problema.
Ver originalesResponder0
DefiPlaybook
· 08-03 21:07
Analizando los datos, el problema de explosión de estado ya ha afectado al 87% de los nodos on-chain.
Vitalik analiza el futuro desarrollo de Ethereum: Análisis del plan The Purge
Vitalik: El posible futuro de Ethereum, The Purge
Uno de los desafíos que enfrenta Ethereum es que, por defecto, la expansión y complejidad de cualquier protocolo de blockchain tiende a aumentar con el tiempo. Esto ocurre en dos lugares:
Datos históricos: Cualquier transacción realizada y cualquier cuenta creada en cualquier momento de la historia debe ser almacenada permanentemente por todos los clientes y descargada por cualquier nuevo cliente, de modo que se sincronice completamente con la red. Esto resultará en una carga para los clientes y un aumento del tiempo de sincronización a medida que pasa 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 mantener su sostenibilidad a largo plazo, necesitamos ejercer una fuerte presión de retroceso sobre 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 que la blockchain sea grandiosa: la persistencia. Puedes poner un NFT, una carta de amor en los datos de una llamada de transacción, o un contrato inteligente que contenga un millón de dólares en la cadena, entrar en una cueva durante diez años y salir para descubrir que aún está allí, esperando que lo leas e interactúes. Para que DApp pueda descentralizarse completamente y eliminar las claves de actualización con confianza, necesitan estar seguros de que sus dependencias no se actualizarán de una manera que las perjudique - especialmente L1 en sí mismo.
Si nos comprometemos a equilibrar estas dos demandas y a minimizar o revertir la obsolescencia, la complejidad y el deterioro al mismo tiempo que mantenemos la continuidad, es absolutamente posible. Los organismos pueden lograr esto: aunque la mayoría de los organismos envejecen con el tiempo, algunos afortunados no lo hacen. Incluso los sistemas sociales pueden tener una vida útil muy larga. En ciertos casos, Ethereum ya ha tenido éxito: la prueba de trabajo ha desaparecido, el código de operación SELFDESTRUCT ha desaparecido en su mayor parte, y los nodos de la cadena de referencia han almacenado datos antiguos por un máximo de seis meses. Encontrar este camino para Ethereum de una manera más general y avanzar hacia un resultado final estable a largo plazo es el desafío definitivo para la escalabilidad a largo plazo de Ethereum, la sostenibilidad técnica e incluso la seguridad.
The Purge: Objetivos principales.
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
Estado de expiración（状态到期）
Limpieza de características
Expiración de historial
¿Qué problema resuelve?
Hasta el momento de redactar 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 varios cientos de GB de espacio en disco para el cliente de consenso. La mayor parte de esto es histórico: datos sobre bloques históricos, transacciones y recibos, la mayoría de los cuales tienen varios años de antigüedad. Esto significa que incluso si el límite de Gas no aumenta en absoluto, el tamaño del nodo seguirá aumentando cientos de GB cada año.
¿Qué es eso y cómo funciona?
Una característica clave de simplificación del problema de almacenamiento histórico es que, dado que cada bloque apunta al bloque anterior a través de enlaces hash (y otras estructuras), es suficiente alcanzar consenso sobre el actual para alcanzar consenso sobre el histórico. Mientras la red alcance 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 N/2-of-N, mientras que la historia es un modelo de confianza N-of-N.
Esto nos ofrece muchas opciones sobre cómo almacenar el historial. Una elección natural es una red donde cada nodo solo almacena una pequeña parte de los datos. Así es como han funcionado las redes de semillas durante décadas: aunque la red almacena y distribuye millones de archivos en total, cada participante solo almacena y distribuye unos pocos de ellos. Quizás contrariamente a la intuición, este enfoque ni siquiera necesariamente reduce la robustez de los datos. Si podemos construir una red con 100,000 nodos, donde cada nodo almacena aleatoriamente el 10% del historial, entonces cada dato se copiará 10,000 veces - lo que es exactamente el mismo factor de copia que una red de 10,000 nodos, donde cada nodo almacena todo.
Hoy en día, Ethereum ha comenzado a alejarse 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. Los blobs solo almacenan 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 de 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 usar 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 colocar los datos de ejecución y consenso en el blob.
¿Qué conexiones tiene con la investigación existente?
EIP-4444；
Torrents y EIP-4444；
Portal de red;
Red de puertas 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 se necesita hacer, qué se debe considerar?
El trabajo principal restante incluye construir e integrar una solución distribuida específica para almacenar el historial ------ al menos el historial de ejecución, pero eventualmente también incluirá el consenso y los blobs. La solución más sencilla es (i) simplemente introducir bibliotecas torrent existentes, así como (ii) una solución nativa de Ethereum llamada Portal Network. Una vez que introduzcamos cualquiera de estas, podremos abrir EIP-4444. EIP-4444 en sí no requiere un hard fork, pero sí necesita una nueva versión del protocolo de red. Por lo tanto, vale la pena habilitarlo para todos los clientes al mismo tiempo, de lo contrario, existe el riesgo de que los clientes fallen debido a que se conectan a otros nodos esperando descargar el historial completo, pero en realidad no lo obtienen.
Las principales compensaciones implican cómo nos esforzamos por proporcionar datos históricos "antiguos". La solución más simple es dejar de almacenar datos históricos antiguos mañana y depender de los nodos archivados 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 los registros de manera distribuida. Aquí, "cuánto esfuerzo ponemos" 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 extremadamente paranoico para (1) implicaría la prueba de custodia: de hecho, requeriría que cada validador de prueba de participación almacenara un porcentaje determinado del historial y lo verificara de forma criptográfica regularmente para asegurarse de que así lo hicieran. 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 implica el trabajo que ya se ha completado hoy: el Portal ya ha almacenado archivos ERA que contienen toda la historia de Ethereum. Una implementación más completa implicará 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, pueden hacerlo a través de 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 ejecución o el inicio de nodos sea extremadamente fácil, entonces reducir la demanda de almacenamiento histórico podría considerarse más importante que la falta de estado: de los 1.1 TB necesarios para el nodo, aproximadamente 300 GB son estado, y el resto, aproximadamente 800 GB, se ha convertido en histórico. Solo logrando la falta de estado y el EIP-4444 se puede realizar la visión de ejecutar un nodo de Ethereum en un reloj inteligente y configurarlo en solo unos minutos.
La limitación del almacenamiento histórico también hace que los nodos de Ethereum más recientes sean más viables, ya que solo admiten la versión más reciente del protocolo, lo que los hace más simples. 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 el cliente almacene el historial, la demanda de almacenamiento del cliente seguirá creciendo, aproximadamente 50 GB cada 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 generará una carga para los clientes de Ethereum, tanto ahora como en el futuro.
El estado es más difícil de "expirar" que la historia, porque el EVM está diseñado fundamentalmente en torno a la suposición de que una vez que se crea un objeto de estado, siempre existirá y podrá ser leído por cualquier transacción en cualquier momento. Si introducimos la falta de estado, algunos piensan que este problema tal vez no sea tan malo: solo las clases de constructores de bloques dedicadas necesitan almacenar realmente el estado, mientras que todos los demás nodos (¡incluso aquellos que generan listas!) pueden funcionar sin estado. Sin embargo, hay una opinión que sostiene que no queremos depender demasiado de la falta de estado; 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 crea un nuevo objeto de estado (lo que 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 que no se ha 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 hacerlo de una manera que logre tres objetivos:
Eficiencia: no se necesita 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 sus posiciones de Ether, ERC20, NFT y CDP...
Amigabilidad para los 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 satisfacer estos objetivos hace que resolver problemas sea muy sencillo. Por ejemplo, puede hacer que cada objeto de estado también almacene un contador de fecha de expiración (que se puede extender quemando ETH, lo cual podría ocurrir automáticamente en cualquier momento al leer o escribir), y tener un proceso que recorra el estado para eliminar los objetos de estado con fecha de expiración. Sin embargo, esto introduce cálculos adicionales (incluso requerimientos de almacenamiento), y definitivamente no puede satisfacer los requisitos de facilidad de uso. A los desarrolladores también les resulta difícil razonar sobre las situaciones límite en las que los valores almacenados a veces se restablecen a cero. Si establece un temporizador de expiración dentro del contrato, esto técnicamente facilitaría la vida a los desarrolladores, pero complicaría 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 tratando de resolver durante años, incluyendo propuestas como "alquiler de blockchain" y "renovación". Al final, combinamos las mejores partes de las propuestas y nos concentramos en dos categorías de "las soluciones conocidas menos malas":
Expiración parcial del estado
Algunas propuestas de estado de vencimiento siguen los mismos principios. Dividimos el estado en bloques. Todos almacenan permanentemente el "mapeo superior".