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 en cualquier momento de la historia y cualquier cuenta creada debe ser almacenada permanentemente por todos los clientes y descargada por cualquier nuevo cliente, de modo que se sincronice completamente con la red. Esto llevará a que la carga del cliente y el tiempo de sincronización aumenten continuamente 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 lleva a un aumento en la complejidad del código a lo largo del tiempo.
Para que Ethereum pueda mantenerse a largo plazo, necesitamos ejercer una fuerte presión inversa 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 hace grande a la blockchain: la persistencia. Puedes poner un NFT, una carta de amor en los datos de llamada de 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 al salir descubrir que todavía está allí esperando que lo leas e interactúes. Para que las DApps se descentralicen por completo sin preocupaciones y eliminen las claves de actualización, necesitan estar seguras de que sus dependencias no se actualizarán de una manera que las destruya - especialmente la L1 en sí.
Si nos decidimos a encontrar un equilibrio entre estas dos demandas y a minimizar o revertir la obsolescencia, la complejidad y el deterioro mientras mantenemos la continuidad, esto 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 ú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 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.
Índice del artículo:
Historia de caducidad(registro histórico de caducidad)
Estado de expiración ( estado de expiración )
Limpieza de características (
Expiración de historial
) ¿Qué problema resuelve?
Hasta el momento en que se escribió 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 gran mayoría de esto es histórico: datos sobre bloques históricos, transacciones y recibos, la mayoría de los cuales tienen varios años. 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? ¿Cómo funciona?
Una característica clave de simplificación del problema del almacenamiento histórico es que, dado que cada bloque está vinculado por hash ### y otras estructuras ( al bloque anterior, es suficiente alcanzar un consenso sobre el presente para alcanzar un consenso sobre el pasado. Siempre que la red alcance consenso sobre el bloque más reciente, cualquier bloque histórico, transacción o estado ), saldo de cuentas, números aleatorios, código, almacenamiento ( puede ser proporcionado por cualquier participante único junto con la prueba de Merkle, y esta prueba permite a cualquier otra persona 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 brinda muchas opciones sobre cómo almacenar el historial. Una opción natural es una red donde cada nodo almacena solo una pequeña parte de los datos. Esta ha sido la forma en que han operado 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 en contra de la intuición, este enfoque ni siquiera necesariamente reduce la robustez de los datos. Si al hacer que los nodos sean más económicos de operar, podemos construir una red de 100,000 nodos, donde cada nodo almacena aleatoriamente el 10% del historial, entonces cada dato será copiado 10,000 veces - 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 deshacerse del modelo en el que todos los nodos almacenan permanentemente toda la historia. El bloque de consenso ) está relacionado con la parte del consenso de prueba de participación que solo almacena aproximadamente 6 meses. Blob almacena solo 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 ( que podría ser de aproximadamente 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 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 simple probablemente sea reutilizar estos códigos de borrado y también colocar los datos de ejecución y consenso del bloque dentro del blob.
( ¿Qué conexiones tiene 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 se necesita hacer, qué hay que 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 en última instancia también incluirá el consenso y los blobs. La solución más simple es )i### introducir simplemente una biblioteca torrent existente, así como (ii) una solución nativa de Ethereum llamada Portal Network. Una vez que introduzcamos cualquiera de estas, podremos habilitar 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, tiene valor habilitarlo para todos los clientes al mismo tiempo, de lo contrario, existe el riesgo de que los clientes fallen al conectarse a otros nodos con la expectativa de 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 simple es dejar de almacenar datos históricos antiguos mañana y depender de los nodos archivados 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 registros de manera distribuida. Aquí, "cuánto nos esforzamos" tiene dos dimensiones:
¿Cómo nos esforzamos por asegurar que el mayor conjunto de nodos realmente almacene todos los datos?
¿Qué tan profunda es la integración del almacenamiento histórico en el protocolo?
Un enfoque extremadamente paranoico para ( implicaría la prueba de custodia: en realidad, exigiría que cada validador de prueba de participación almacene un cierto porcentaje de registros históricos y los verifique de manera criptográfica de forma regular. Un enfoque más suave sería establecer un estándar voluntario para el porcentaje de historia 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ía conectar realmente esto 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 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 ejecutar o iniciar nodos sea extremadamente fácil, entonces reducir los requisitos 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, mientras que los aproximadamente 800 GB restantes se han convertido en historia. Solo al lograr la falta de estado y EIP-4444, se puede 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, al admitir solo 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 parte de la 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 cada año, ya que el estado continúa creciendo: saldos de cuentas y números aleatorios, código de contrato y almacenamiento de contrato. Los usuarios pueden pagar una tarifa única, lo que a su vez genera una carga para los clientes de Ethereum actuales y futuros.
El estado es más difícil de "expirar" que la historia, porque la EVM está diseñada fundamentalmente en torno a esta suposición: 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, algunas personas creen que este problema tal vez no sea tan grave: solo las clases de constructores de bloques especializadas necesitan almacenar realmente el estado, mientras que todos los demás nodos ( incluso incluyendo la generación de 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 finalmente podríamos querer hacer que el estado expire para mantener la descentralización de Ethereum.
¿Qué es, cómo funciona?
Hoy, cuando crea un nuevo objeto de estado, ( 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 espacio de almacenamiento que no se ha tocado anteriormente ), el objeto de estado permanece en este 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 manera que se cumplan 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 ETH, ERC20, NFT y 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. ( se puede extender la fecha de caducidad mediante la quema de ETH, lo que puede ocurrir automáticamente al leer o escribir en cualquier momento ), y hay un proceso que recorre el estado para eliminar los objetos de estado con fecha de caducidad. Sin embargo, esto introduce una carga computacional adicional ) e 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 que involucran valores de almacenamiento que a veces se restablecen a cero. Si configura un temporizador de caducidad dentro del alcance del contrato, esto técnicamente facilitará la vida de los desarrolladores, pero complicará más 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, incluidos los proyectos de "renta de blockchain" y "regeneración". Al final, combinamos las mejores partes de las propuestas y nos concentramos en dos categorías de "soluciones conocidas como las menos malas":
Soluciones para el estado parcialmente caducado
Sugerencias de vencimiento de estado basadas en el ciclo de direcciones.
) Expiración parcial del estado
Propuestas de estado parcialmente vencidas siguen los mismos principios. Dividimos el estado en bloques. Cada persona almacena permanentemente un "mapeo superior", donde los bloques pueden estar vacíos o no vacíos. Solo se almacena la información en cada bloque si se ha accedido recientemente a esos datos. Existe un mecanismo de "resurrección" que se activa si ya no se almacena.
 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.
11 me gusta
Recompensa
11
7
Compartir
Comentar
0/400
MidnightGenesis
· hace5h
La monitorización on-chain realmente ha mostrado algunos códigos interesantes. La reducción de carga no puede esperar.
Ver originalesResponder0
SignatureVerifier
· hace23h
técnicamente hablando, estoy bastante preocupado por la insuficiente verificación de validación en este mecanismo de purga... requiere una auditoría de seguridad exhaustiva, para ser honesto
Ver originalesResponder0
UnluckyLemur
· 08-03 10:23
Impuesto de moneda 100 monedas es suficiente
Ver originalesResponder0
DegenApeSurfer
· 08-03 10:22
Reducir la carga es demasiado difícil, ¿no?
Ver originalesResponder0
OldLeekNewSickle
· 08-03 10:20
¿Datos reducidos de la cadena o datos de Ser engañados? Los tontos mayores dicen que no entienden.
Ver originalesResponder0
NonFungibleDegen
· 08-03 10:18
ngmi con esa hinchazón ser... purga o todos estaremos mal de verdad de verdad
Ethereum El Plan Purge: Soltar los requisitos de almacenamiento y simplificar la complejidad del protocolo
Futuro posible 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 en cualquier momento de la historia y cualquier cuenta creada debe ser almacenada permanentemente por todos los clientes y descargada por cualquier nuevo cliente, de modo que se sincronice completamente con la red. Esto llevará a que la carga del cliente y el tiempo de sincronización aumenten continuamente 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 lleva a un aumento en la complejidad del código a lo largo del tiempo.
Para que Ethereum pueda mantenerse a largo plazo, necesitamos ejercer una fuerte presión inversa 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 hace grande a la blockchain: la persistencia. Puedes poner un NFT, una carta de amor en los datos de llamada de 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 al salir descubrir que todavía está allí esperando que lo leas e interactúes. Para que las DApps se descentralicen por completo sin preocupaciones y eliminen las claves de actualización, necesitan estar seguras de que sus dependencias no se actualizarán de una manera que las destruya - especialmente la L1 en sí.
Si nos decidimos a encontrar un equilibrio entre estas dos demandas y a minimizar o revertir la obsolescencia, la complejidad y el deterioro mientras mantenemos la continuidad, esto 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 ú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 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.
Índice del artículo:
Historia de caducidad(registro histórico de caducidad)
Estado de expiración ( estado de expiración )
Limpieza de características (
Expiración de historial
) ¿Qué problema resuelve?
Hasta el momento en que se escribió 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 gran mayoría de esto es histórico: datos sobre bloques históricos, transacciones y recibos, la mayoría de los cuales tienen varios años. 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? ¿Cómo funciona?
Una característica clave de simplificación del problema del almacenamiento histórico es que, dado que cada bloque está vinculado por hash ### y otras estructuras ( al bloque anterior, es suficiente alcanzar un consenso sobre el presente para alcanzar un consenso sobre el pasado. Siempre que la red alcance consenso sobre el bloque más reciente, cualquier bloque histórico, transacción o estado ), saldo de cuentas, números aleatorios, código, almacenamiento ( puede ser proporcionado por cualquier participante único junto con la prueba de Merkle, y esta prueba permite a cualquier otra persona 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 brinda muchas opciones sobre cómo almacenar el historial. Una opción natural es una red donde cada nodo almacena solo una pequeña parte de los datos. Esta ha sido la forma en que han operado 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 en contra de la intuición, este enfoque ni siquiera necesariamente reduce la robustez de los datos. Si al hacer que los nodos sean más económicos de operar, podemos construir una red de 100,000 nodos, donde cada nodo almacena aleatoriamente el 10% del historial, entonces cada dato será copiado 10,000 veces - 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 deshacerse del modelo en el que todos los nodos almacenan permanentemente toda la historia. El bloque de consenso ) está relacionado con la parte del consenso de prueba de participación que solo almacena aproximadamente 6 meses. Blob almacena solo 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 ( que podría ser de aproximadamente 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 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 simple probablemente sea reutilizar estos códigos de borrado y también colocar los datos de ejecución y consenso del bloque dentro del blob.
( ¿Qué conexiones tiene 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 se necesita hacer, qué hay que 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 en última instancia también incluirá el consenso y los blobs. La solución más simple es )i### introducir simplemente una biblioteca torrent existente, así como (ii) una solución nativa de Ethereum llamada Portal Network. Una vez que introduzcamos cualquiera de estas, podremos habilitar 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, tiene valor habilitarlo para todos los clientes al mismo tiempo, de lo contrario, existe el riesgo de que los clientes fallen al conectarse a otros nodos con la expectativa de 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 simple es dejar de almacenar datos históricos antiguos mañana y depender de los nodos archivados 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 registros de manera distribuida. Aquí, "cuánto nos esforzamos" tiene dos dimensiones:
¿Cómo nos esforzamos por asegurar que el mayor conjunto de nodos realmente almacene todos los datos?
¿Qué tan profunda es la integración del almacenamiento histórico en el protocolo?
Un enfoque extremadamente paranoico para ( implicaría la prueba de custodia: en realidad, exigiría que cada validador de prueba de participación almacene un cierto porcentaje de registros históricos y los verifique de manera criptográfica de forma regular. Un enfoque más suave sería establecer un estándar voluntario para el porcentaje de historia 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ía conectar realmente esto 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 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 ejecutar o iniciar nodos sea extremadamente fácil, entonces reducir los requisitos 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, mientras que los aproximadamente 800 GB restantes se han convertido en historia. Solo al lograr la falta de estado y EIP-4444, se puede 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, al admitir solo 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 parte de la 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 cada año, ya que el estado continúa creciendo: saldos de cuentas y números aleatorios, código de contrato y almacenamiento de contrato. Los usuarios pueden pagar una tarifa única, lo que a su vez genera una carga para los clientes de Ethereum actuales y futuros.
El estado es más difícil de "expirar" que la historia, porque la EVM está diseñada fundamentalmente en torno a esta suposición: 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, algunas personas creen que este problema tal vez no sea tan grave: solo las clases de constructores de bloques especializadas necesitan almacenar realmente el estado, mientras que todos los demás nodos ( incluso incluyendo la generación de 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 finalmente podríamos querer hacer que el estado expire para mantener la descentralización de Ethereum.
¿Qué es, cómo funciona?
Hoy, cuando crea un nuevo objeto de estado, ( 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 espacio de almacenamiento que no se ha tocado anteriormente ), el objeto de estado permanece en este 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 manera que se cumplan 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 ETH, ERC20, NFT y 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. ( se puede extender la fecha de caducidad mediante la quema de ETH, lo que puede ocurrir automáticamente al leer o escribir en cualquier momento ), y hay un proceso que recorre el estado para eliminar los objetos de estado con fecha de caducidad. Sin embargo, esto introduce una carga computacional adicional ) e 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 que involucran valores de almacenamiento que a veces se restablecen a cero. Si configura un temporizador de caducidad dentro del alcance del contrato, esto técnicamente facilitará la vida de los desarrolladores, pero complicará más 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, incluidos los proyectos de "renta de blockchain" y "regeneración". Al final, combinamos las mejores partes de las propuestas y nos concentramos en dos categorías de "soluciones conocidas como las menos malas":
) Expiración parcial del estado
Propuestas de estado parcialmente vencidas siguen los mismos principios. Dividimos el estado en bloques. Cada persona almacena permanentemente un "mapeo superior", donde los bloques pueden estar vacíos o no vacíos. Solo se almacena la información en cada bloque si se ha accedido recientemente a esos datos. Existe un mecanismo de "resurrección" que se activa si ya no se almacena.
![Vitalik: El posible futuro de Ethereum, The Purge](