Un desafío que enfrenta Ethereum es que, por defecto, la expansión y complejidad de cualquier protocolo de blockchain aumentan con el tiempo. Esto ocurre en dos aspectos:
Datos históricos: todas las transacciones realizadas y las cuentas creadas en cualquier momento deben ser almacenadas de forma permanente por todos los clientes y ser descargadas por cualquier nuevo cliente para sincronizarse completamente con la red. Esto resulta en un aumento continuo de la carga del cliente y del tiempo de sincronización, 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 de la complejidad del código 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 preservar una de las propiedades clave que hacen que la blockchain sea grandiosa: la persistencia. Puedes poner un NFT, una carta de amor 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 con él. Para que las DApp se sientan completamente descentralizadas 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 L1 en sí misma.
Si nos decidimos a encontrar un equilibrio entre estas dos demandas, y al mismo tiempo minimizar o revertir la hinchazón, la complejidad y el declive 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 extremadamente larga. En ciertos casos, Ethereum ya ha tenido éxito: la prueba de trabajo ha desaparecido, el opcode SELFDESTRUCT ha desaparecido en su mayor parte, y los nodos de la cadena de señal 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 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.
La Purga: 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 expiración( registros históricos de expiración)
Estado de expiración( estado de expiración)
Feature cleanup( limpieza de características)
Historial de caducidad
¿Qué problema se resuelve?
Hasta la fecha de redacción de 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 historia: 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 a través de hash ( y otras estructuras ) al bloque anterior, 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 la prueba de Merkle, y dicha 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 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 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 unos pocos de esos archivos. Quizás en contra de la intuición, este enfoque ni siquiera necesariamente reducirá la robustez de los datos. Si al hacer que operar los nodos sea más asequible, podemos construir una red con 100,000 nodos, donde cada nodo almacene aleatoriamente el 10% del historial, entonces cada dato será copiado 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 donde 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. Los Blob solo almacenan 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 peer-to-peer compuesta por nodos de Ethereum que almacenen 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, el 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 de bloques dentro del blob.
(# ¿Qué conexiones tiene con la investigación existente?
EIP-4444;
Torrents y EIP-4444;
Red de puerta de enlace;
Red de puerta de enlace 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 considerar?
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 que eventualmente también incluya consenso y blobs. La solución más simple es )i### simplemente introducir bibliotecas torrent existentes, así como (ii) una solución nativa de Ethereum llamada red Portal. Una vez que se introduzca cualquiera de estas, podremos activar 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, 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 proporcionar datos históricos "antiguos". La solución más sencilla es dejar de almacenar historia antigua a partir de mañana y depender de 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 registros de manera distribuida. Aquí, "cuánto esfuerzo ponemos" tiene dos dimensiones:
¿Cómo nos aseguramos de 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 pruebas de custodia: en realidad, exigiría que cada validador de prueba de participación almacenara una cierta proporción de registros históricos y verificara periódicamente de manera criptográfica si lo estaban haciendo. Un enfoque más suave 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: 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, puedan lograrlo mediante la sincronización directa desde la red de 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 necesidad de almacenamiento histórico puede considerarse más importante que la naturaleza sin estado: de los 1.1 TB requeridos por el nodo, aproximadamente 300 GB son estado, y los restantes aproximadamente 800 GB se han convertido en históricos. Solo al lograr la naturaleza sin estado y el EIP-4444 se puede hacer realidad 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 la implementación de nodos de Ethereum más recientes sea más viable, 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 forma segura todo el código relacionado con la prueba de trabajo.
) Expiración del estado
¿Qué problema se 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, ya que el estado continúa creciendo: saldos de cuentas y números aleatorios, código de contratos y almacenamiento de contratos. Los usuarios pueden pagar una tarifa única, lo que así carga permanentemente a los clientes de Ethereum ahora y 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 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 dedicados necesitan almacenar realmente el estado, mientras que todos los demás nodos ### incluso incluyen la generación de listas! ### pueden funcionar sin estado. Sin embargo, hay una opinión que sostiene que no queremos depender demasiado de la falta de estado, y que en última instancia, quizás deseemos 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 la nueva cuenta, ( ii ) creando una nueva cuenta con código, ( iii ) configurando una ranura de almacenamiento que no se ha tocado anteriormente (, y ese objeto de estado permanece en ese estado para siempre. Por el contrario, 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 los tres objetivos:
Eficiencia: no se necesitan grandes cálculos adicionales para ejecutar 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 ETH, ERC20, NFT, posiciones de CDP...
Amigable 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 actualizadas 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 podría 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 requisitos adicionales de cálculo ( e incluso 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 de almacenamiento a veces se restablecen a cero. Si configura un temporizador de caducidad dentro del alcance del contrato, esto técnicamente facilita la vida de los desarrolladores, pero complica la economía: los desarrolladores deben considerar cómo "trasladar" los costos de almacenamiento continuos a los usuarios.
Estos son problemas que la comunidad de desarrollo central de Ethereum ha estado tratando de resolver durante años, incluidos propuestas como "renta de blockchain" y "regeneración". Al final, combinamos las mejores partes de las propuestas y nos centramos en dos categorías de "las soluciones conocidas menos malas":
Soluciones para estados parcialmente expirados
Sugerencia de vencimiento de estado basada en el ciclo de direcciones.
(# Expiración parcial del estado
Algunas propuestas de estado que han expirado siguen los mismos principios. Dividimos el estado en bloques. Todos almacenan de forma permanente el "mapeo superior", donde los bloques pueden estar vacíos o no vacíos. Los datos en cada bloque solo se almacenan si se han accedido recientemente. Hay un mecanismo de "resurrección" que se activa si ya no se almacenan.
Las principales diferencias entre estas propuestas son: ) i ### cómo definimos "reciente", y ( ii ) cómo definimos "bloque"? Una propuesta concreta es EIP-7736, que se basa en el diseño de "hoja y tallo" introducido para el árbol Verkle ( a pesar de ser compatible con cualquier forma de estado sin estado, como el árbol binario ). En este diseño, los encabezados, códigos y espacios de almacenamiento adyacentes se almacenan bajo el mismo "tallo". Los datos almacenados bajo un tallo pueden ser hasta 256 * 31 = 7,936.
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.
11 me gusta
Recompensa
11
7
Compartir
Comentar
0/400
NotGonnaMakeIt
· 07-16 18:58
La enorme Cadena de bloques ha agotado las nuevas máquinas, ¿verdad?
Ver originalesResponder0
MysteryBoxBuster
· 07-15 00:26
Esta cadena se ha vuelto cada vez más pesada.
Ver originalesResponder0
SquidTeacher
· 07-14 03:56
Está bien tener ideas.
Ver originalesResponder0
GasFeeCrier
· 07-14 03:53
¿Ahora es el momento más gordo, verdad?
Ver originalesResponder0
DefiOldTrickster
· 07-14 03:52
On-chain, otra vez es un gran profeta.
Ver originalesResponder0
GasBandit
· 07-14 03:47
¿Cuándo podré superar la inflación?
Ver originalesResponder0
StablecoinArbitrageur
· 07-14 03:29
*ajusta hojas de cálculo* basado en mi análisis de correlación, la eficiencia de purga = sostenibilidad de la red * -0.89
Ethereum The Purge: crear un ecosistema de cadena de bloques sostenible a largo plazo
Futuro posible de Ethereum: The Purge
Un desafío que enfrenta Ethereum es que, por defecto, la expansión y complejidad de cualquier protocolo de blockchain aumentan con el tiempo. Esto ocurre en dos aspectos:
Datos históricos: todas las transacciones realizadas y las cuentas creadas en cualquier momento deben ser almacenadas de forma permanente por todos los clientes y ser descargadas por cualquier nuevo cliente para sincronizarse completamente con la red. Esto resulta en un aumento continuo de la carga del cliente y del tiempo de sincronización, 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 de la complejidad del código 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 preservar una de las propiedades clave que hacen que la blockchain sea grandiosa: la persistencia. Puedes poner un NFT, una carta de amor 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 con él. Para que las DApp se sientan completamente descentralizadas 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 L1 en sí misma.
Si nos decidimos a encontrar un equilibrio entre estas dos demandas, y al mismo tiempo minimizar o revertir la hinchazón, la complejidad y el declive 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 extremadamente larga. En ciertos casos, Ethereum ya ha tenido éxito: la prueba de trabajo ha desaparecido, el opcode SELFDESTRUCT ha desaparecido en su mayor parte, y los nodos de la cadena de señal 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 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.
La Purga: 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 expiración( registros históricos de expiración) Estado de expiración( estado de expiración) Feature cleanup( limpieza de características)
Historial de caducidad
¿Qué problema se resuelve?
Hasta la fecha de redacción de 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 historia: 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 a través de hash ( y otras estructuras ) al bloque anterior, 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 la prueba de Merkle, y dicha 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 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 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 unos pocos de esos archivos. Quizás en contra de la intuición, este enfoque ni siquiera necesariamente reducirá la robustez de los datos. Si al hacer que operar los nodos sea más asequible, podemos construir una red con 100,000 nodos, donde cada nodo almacene aleatoriamente el 10% del historial, entonces cada dato será copiado 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 donde 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. Los Blob solo almacenan 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 peer-to-peer compuesta por nodos de Ethereum que almacenen 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, el 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 de bloques dentro del blob.
(# ¿Qué conexiones tiene con la investigación existente?
EIP-4444;
Torrents y EIP-4444;
Red de puerta de enlace;
Red de puerta de enlace 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 considerar?
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 que eventualmente también incluya consenso y blobs. La solución más simple es )i### simplemente introducir bibliotecas torrent existentes, así como (ii) una solución nativa de Ethereum llamada red Portal. Una vez que se introduzca cualquiera de estas, podremos activar 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, 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 proporcionar datos históricos "antiguos". La solución más sencilla es dejar de almacenar historia antigua a partir de mañana y depender de 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 registros de manera distribuida. Aquí, "cuánto esfuerzo ponemos" tiene dos dimensiones:
¿Cómo nos aseguramos de 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 pruebas de custodia: en realidad, exigiría que cada validador de prueba de participación almacenara una cierta proporción de registros históricos y verificara periódicamente de manera criptográfica si lo estaban haciendo. Un enfoque más suave 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: 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, puedan lograrlo mediante la sincronización directa desde la red de 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 necesidad de almacenamiento histórico puede considerarse más importante que la naturaleza sin estado: de los 1.1 TB requeridos por el nodo, aproximadamente 300 GB son estado, y los restantes aproximadamente 800 GB se han convertido en históricos. Solo al lograr la naturaleza sin estado y el EIP-4444 se puede hacer realidad 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 la implementación de nodos de Ethereum más recientes sea más viable, 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 forma segura todo el código relacionado con la prueba de trabajo.
) Expiración del estado
¿Qué problema se 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, ya que el estado continúa creciendo: saldos de cuentas y números aleatorios, código de contratos y almacenamiento de contratos. Los usuarios pueden pagar una tarifa única, lo que así carga permanentemente a los clientes de Ethereum ahora y 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 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 dedicados necesitan almacenar realmente el estado, mientras que todos los demás nodos ### incluso incluyen la generación de listas! ### pueden funcionar sin estado. Sin embargo, hay una opinión que sostiene que no queremos depender demasiado de la falta de estado, y que en última instancia, quizás deseemos 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 la nueva cuenta, ( ii ) creando una nueva cuenta con código, ( iii ) configurando una ranura de almacenamiento que no se ha tocado anteriormente (, y ese objeto de estado permanece en ese estado para siempre. Por el contrario, 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 los tres objetivos:
Eficiencia: no se necesitan grandes cálculos adicionales para ejecutar 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 ETH, ERC20, NFT, posiciones de CDP...
Amigable 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 actualizadas 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 podría 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 requisitos adicionales de cálculo ( e incluso 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 de almacenamiento a veces se restablecen a cero. Si configura un temporizador de caducidad dentro del alcance del contrato, esto técnicamente facilita la vida de los desarrolladores, pero complica la economía: los desarrolladores deben considerar cómo "trasladar" los costos de almacenamiento continuos a los usuarios.
Estos son problemas que la comunidad de desarrollo central de Ethereum ha estado tratando de resolver durante años, incluidos propuestas como "renta de blockchain" y "regeneración". Al final, combinamos las mejores partes de las propuestas y nos centramos en dos categorías de "las soluciones conocidas menos malas":
(# Expiración parcial del estado
Algunas propuestas de estado que han expirado siguen los mismos principios. Dividimos el estado en bloques. Todos almacenan de forma permanente el "mapeo superior", donde los bloques pueden estar vacíos o no vacíos. Los datos en cada bloque solo se almacenan si se han accedido recientemente. Hay un mecanismo de "resurrección" que se activa si ya no se almacenan.
Las principales diferencias entre estas propuestas son: ) i ### cómo definimos "reciente", y ( ii ) cómo definimos "bloque"? Una propuesta concreta es EIP-7736, que se basa en el diseño de "hoja y tallo" introducido para el árbol Verkle ( a pesar de ser compatible con cualquier forma de estado sin estado, como el árbol binario ). En este diseño, los encabezados, códigos y espacios de almacenamiento adyacentes se almacenan bajo el mismo "tallo". Los datos almacenados bajo un tallo pueden ser hasta 256 * 31 = 7,936.