Un desafío 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 aspectos:
Datos históricos: Todas las transacciones realizadas y todas las cuentas creadas en cualquier momento de la historia deben ser almacenadas permanentemente por todos los clientes y descargadas por cualquier nuevo cliente, para que se sincronicen completamente con la red. Esto llevará a que la carga del cliente y el tiempo de sincronización aumenten con el tiempo, incluso si la capacidad de la cadena se mantiene constante.
Función del protocolo: agregar nuevas funciones es mucho más fácil que eliminar funciones antiguas, lo que provoca que la complejidad del código aumente con el tiempo.
Para que Ethereum pueda mantenerse a largo plazo, necesitamos ejercer una fuerte presión contraria sobre estas dos tendencias, reduciendo la complejidad y la expansión con el tiempo. Pero al mismo tiempo, necesitamos conservar 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 llamada de una 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 todavía está allí esperando que lo leas e interactúes. Para que las DApps se descentralicen completamente y eliminen las claves de actualización, necesitan estar seguros de que sus dependencias no se actualizarán de una manera que las destruya, especialmente la L1 en sí.
Si nos decidimos a equilibrar estas dos demandas y a minimizar o revertir la burocracia, la complejidad y el deterioro mientras mantenemos la continuidad, es absolutamente posible. Los organismos pueden hacerlo: 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 muy larga. En ciertos casos, Ethereum 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 balizas han almacenado datos antiguos durante un máximo de 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 para 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.
Historial de expiración
¿Qué problema resuelve?
Hasta el momento de redactar este artículo, un nodo de Ethereum completamente sincronizado requiere 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 historia: 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 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. Siempre que la red alcance consenso sobre el bloque más reciente, cualquier bloque histórico, transacción o estado (saldo de cuentas, número aleatorio, código, almacenamiento) puede ser proporcionado por cualquier participante individual junto con una prueba Merkle, y dicha prueba permite a cualquier otro verificar 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 los registros históricos. Una elección natural es una red en la que cada nodo almacena solo una pequeña parte de los datos. Esta es la forma en que 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 algunos de esos archivos. Quizás contra la intuición, este enfoque ni siquiera necesariamente reduce la robustez de los datos. Si podemos establecer una red con 100,000 nodos, donde cada nodo almacena aleatoriamente el 10% de los registros históricos, entonces cada dato será replicado 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 desprenderse 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 Blob solo se almacenan durante aproximadamente 18 días. EIP-4444 tiene como objetivo introducir un período de almacenamiento de un año para bloques históricos y 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 peer-to-peer compuesta por nodos de Ethereum, que almacena datos antiguos de manera distribuida.
Los códigos de borrado se pueden utilizar para mejorar 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
Red de portal
Red de puerta de enlace y EIP-4444
Almacenamiento y recuperación distribuidos de objetos SSZ en Portal
¿Cómo aumentar el límite de gas (Paradigm)
¿Qué más se necesita hacer y qué se debe sopesar?
El trabajo principal restante incluye construir e integrar una solución distribuida específica para almacenar registros históricos------al menos los registros de ejecución, pero finalmente también incluirá consenso y blob. La solución más simple es (i) simplemente introducir bibliotecas torrent existentes, así como (ii) llamada solución nativa de Ethereum conocida como Portal Network. Una vez que introduzcamos cualquiera de estas, podemos abrir EIP-4444. EIP-4444 en sí no requiere un hard fork, pero sí requiere una nueva versión del protocolo de red. Por lo tanto, es valioso habilitarlo para todos los clientes al mismo tiempo, 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.
Las principales consideraciones implican cómo nos esforzamos por ofrecer datos históricos "antiguos". La solución más sencilla es dejar de almacenar historia antigua mañana y depender de los nodos de archivo existentes y de 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 por asegurar que el conjunto de nodos más grande realmente almacene todos los datos?
¿Qué tan profundo es la integración del almacenamiento histórico en el protocolo?
Un enfoque extremadamente obsesivo para (1) implicaría la prueba de custodia: requerir efectivamente que cada validador de prueba de participación almacene un cierto porcentaje de registros históricos y verifique periódicamente de manera criptográfica si lo está haciendo. Un enfoque más moderado sería establecer un estándar voluntario para el porcentaje de historia almacenada 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 quiere 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 ejecución o el inicio de nodos sea extremadamente fácil, entonces reducir la demanda de almacenamiento histórico puede considerarse más importante que la falta de estado: de los 1.1 TB requeridos por el nodo, aproximadamente 300 GB son estado, y los aproximadamente 800 GB restantes se han convertido en históricos. Solo logrando la falta de estado y el EIP-4444 se podrá realizar la visión de ejecutar nodos de Ethereum en un reloj inteligente y configurarlos en solo unos minutos.
Limitar el almacenamiento histórico también hace que los nodos de Ethereum más nuevos sean más viables, ya que solo admiten la última versión 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 manera 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 al año, ya que el estado sigue creciendo: saldos de cuentas y números aleatorios, código de contrato y almacenamiento de contratos. Los usuarios pueden pagar una tarifa única, lo que impondrá una carga a los clientes de Ethereum, tanto en el presente 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 creado 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 el problema quizás no sea tan malo: solo las clases de constructores de bloques especializados necesitan almacenar realmente el estado, mientras que todos los demás nodos (¡incluso aquellos que generan listas!) pueden funcionar sin estado. Sin embargo, hay un punto de vista que sostiene 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 crea un nuevo objeto de estado (esto puede suceder de una de las siguientes tres maneras: (i) enviando ETH a una nueva cuenta, (ii) creando una nueva cuenta mediante código, (iii) configurando un espacio de almacenamiento previamente no tocado), 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 requieren grandes cálculos adicionales para llevar a cabo el proceso de vencimiento.
Facilidad de uso: Si alguien entra en la cueva durante cinco años y regresa, no debería perder el acceso a sus posiciones de Ether, ERC20, NFT, 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 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 vencimiento (que se puede extender quemando ETH, lo que puede 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 fechas de vencimiento. Sin embargo, esto introduce cálculos adicionales (incluso requisitos de almacenamiento), y definitivamente no puede cumplir con 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 restablecen a cero. Si establece un temporizador de vencimiento dentro del alcance del contrato, 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 para resolver durante años, incluidos los conceptos de "alquiler de blockchain" y "regeneració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 direcciones.
Expiración parcial del estado
Parte de las propuestas de estado que han vencido siguen los mismos principios. Dividimos el estado en bloques. Cada uno almacena permanentemente un "mapeo superior", donde los bloques pueden estar vacíos o no vacíos. Solo se almacenan los datos en cada bloque si se ha accedido a esos datos recientemente. Existe un mecanismo de "resurrección" que se activa si ya no se almacenan.
La principal diferencia entre estas propuestas es: (i) cómo definimos "reciente", y (ii) yo
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.
15 me gusta
Recompensa
15
6
Compartir
Comentar
0/400
OnchainGossiper
· hace7h
La sincronización del cliente es tan lenta que me está haciendo vomitar.
Ver originalesResponder0
MidnightSnapHunter
· 07-26 22:22
¿Finalmente V神 va a liquidar?
Ver originalesResponder0
PriceOracleFairy
· 07-24 21:24
el bloat del protocolo ngl es real... las pesadillas de escalado me mantienen despierto a las 3am fr
Ver originalesResponder0
WhaleWatcher
· 07-24 21:14
Vitalik Buterin, ayúdame a calcular los costos de almacenamiento.
Ver originalesResponder0
Degen4Breakfast
· 07-24 21:00
Dile adiós a la hinchazón del sistema.
Ver originalesResponder0
FloorPriceWatcher
· 07-24 20:58
No amo las nuevas funciones, amo el almacenamiento en cero.
Vitalik habla sobre The Purge: el camino hacia la sostenibilidad a largo plazo de Ethereum
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 tiende 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 permanentemente por todos los clientes y descargadas por cualquier nuevo cliente, para que se sincronicen completamente con la red. Esto llevará a que la carga del cliente y el tiempo de sincronización aumenten con el tiempo, incluso si la capacidad de la cadena se mantiene constante.
Función del protocolo: agregar nuevas funciones es mucho más fácil que eliminar funciones antiguas, lo que provoca que la complejidad del código aumente con el tiempo.
Para que Ethereum pueda mantenerse a largo plazo, necesitamos ejercer una fuerte presión contraria sobre estas dos tendencias, reduciendo la complejidad y la expansión con el tiempo. Pero al mismo tiempo, necesitamos conservar 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 llamada de una 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 todavía está allí esperando que lo leas e interactúes. Para que las DApps se descentralicen completamente y eliminen las claves de actualización, necesitan estar seguros de que sus dependencias no se actualizarán de una manera que las destruya, especialmente la L1 en sí.
Si nos decidimos a equilibrar estas dos demandas y a minimizar o revertir la burocracia, la complejidad y el deterioro mientras mantenemos la continuidad, es absolutamente posible. Los organismos pueden hacerlo: 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 muy larga. En ciertos casos, Ethereum 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 balizas han almacenado datos antiguos durante un máximo de 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 para 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.
Historial de expiración
¿Qué problema resuelve?
Hasta el momento de redactar este artículo, un nodo de Ethereum completamente sincronizado requiere 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 historia: 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 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. Siempre que la red alcance consenso sobre el bloque más reciente, cualquier bloque histórico, transacción o estado (saldo de cuentas, número aleatorio, código, almacenamiento) puede ser proporcionado por cualquier participante individual junto con una prueba Merkle, y dicha prueba permite a cualquier otro verificar 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 los registros históricos. Una elección natural es una red en la que cada nodo almacena solo una pequeña parte de los datos. Esta es la forma en que 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 algunos de esos archivos. Quizás contra la intuición, este enfoque ni siquiera necesariamente reduce la robustez de los datos. Si podemos establecer una red con 100,000 nodos, donde cada nodo almacena aleatoriamente el 10% de los registros históricos, entonces cada dato será replicado 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 desprenderse 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 Blob solo se almacenan durante aproximadamente 18 días. EIP-4444 tiene como objetivo introducir un período de almacenamiento de un año para bloques históricos y 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 peer-to-peer compuesta por nodos de Ethereum, que almacena datos antiguos de manera distribuida.
Los códigos de borrado se pueden utilizar para mejorar 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?
¿Qué más se necesita hacer y qué se debe sopesar?
El trabajo principal restante incluye construir e integrar una solución distribuida específica para almacenar registros históricos------al menos los registros de ejecución, pero finalmente también incluirá consenso y blob. La solución más simple es (i) simplemente introducir bibliotecas torrent existentes, así como (ii) llamada solución nativa de Ethereum conocida como Portal Network. Una vez que introduzcamos cualquiera de estas, podemos abrir EIP-4444. EIP-4444 en sí no requiere un hard fork, pero sí requiere una nueva versión del protocolo de red. Por lo tanto, es valioso habilitarlo para todos los clientes al mismo tiempo, 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.
Las principales consideraciones implican cómo nos esforzamos por ofrecer datos históricos "antiguos". La solución más sencilla es dejar de almacenar historia antigua mañana y depender de los nodos de archivo existentes y de 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 por asegurar que el conjunto de nodos más grande realmente almacene todos los datos?
¿Qué tan profundo es la integración del almacenamiento histórico en el protocolo?
Un enfoque extremadamente obsesivo para (1) implicaría la prueba de custodia: requerir efectivamente que cada validador de prueba de participación almacene un cierto porcentaje de registros históricos y verifique periódicamente de manera criptográfica si lo está haciendo. Un enfoque más moderado sería establecer un estándar voluntario para el porcentaje de historia almacenada 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 quiere 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 ejecución o el inicio de nodos sea extremadamente fácil, entonces reducir la demanda de almacenamiento histórico puede considerarse más importante que la falta de estado: de los 1.1 TB requeridos por el nodo, aproximadamente 300 GB son estado, y los aproximadamente 800 GB restantes se han convertido en históricos. Solo logrando la falta de estado y el EIP-4444 se podrá realizar la visión de ejecutar nodos de Ethereum en un reloj inteligente y configurarlos en solo unos minutos.
Limitar el almacenamiento histórico también hace que los nodos de Ethereum más nuevos sean más viables, ya que solo admiten la última versión 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 manera 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 al año, ya que el estado sigue creciendo: saldos de cuentas y números aleatorios, código de contrato y almacenamiento de contratos. Los usuarios pueden pagar una tarifa única, lo que impondrá una carga a los clientes de Ethereum, tanto en el presente 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 creado 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 el problema quizás no sea tan malo: solo las clases de constructores de bloques especializados necesitan almacenar realmente el estado, mientras que todos los demás nodos (¡incluso aquellos que generan listas!) pueden funcionar sin estado. Sin embargo, hay un punto de vista que sostiene 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 crea un nuevo objeto de estado (esto puede suceder de una de las siguientes tres maneras: (i) enviando ETH a una nueva cuenta, (ii) creando una nueva cuenta mediante código, (iii) configurando un espacio de almacenamiento previamente no tocado), 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 requieren grandes cálculos adicionales para llevar a cabo el proceso de vencimiento.
Facilidad de uso: Si alguien entra en la cueva durante cinco años y regresa, no debería perder el acceso a sus posiciones de Ether, ERC20, NFT, 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 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 vencimiento (que se puede extender quemando ETH, lo que puede 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 fechas de vencimiento. Sin embargo, esto introduce cálculos adicionales (incluso requisitos de almacenamiento), y definitivamente no puede cumplir con 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 restablecen a cero. Si establece un temporizador de vencimiento dentro del alcance del contrato, 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 para resolver durante años, incluidos los conceptos de "alquiler de blockchain" y "regeneració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
Parte de las propuestas de estado que han vencido siguen los mismos principios. Dividimos el estado en bloques. Cada uno almacena permanentemente un "mapeo superior", donde los bloques pueden estar vacíos o no vacíos. Solo se almacenan los datos en cada bloque si se ha accedido a esos datos recientemente. Existe un mecanismo de "resurrección" que se activa si ya no se almacenan.
La principal diferencia entre estas propuestas es: (i) cómo definimos "reciente", y (ii) yo