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 de la historia deben ser almacenadas de forma permanente por todos los clientes y ser descargadas por cualquier nuevo cliente para sincronizarse completamente con la red. Esto provoca un aumento constante en la carga del cliente y el tiempo de sincronización, incluso si la capacidad de la cadena se mantiene constante.
Función del protocolo: añadir 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 a estas dos tendencias, reduciendo la complejidad y la expansión con el tiempo. Al mismo tiempo, debemos conservar una de las propiedades clave que hacen grande a la cadena de bloques: la persistencia. Puedes colocar NFT, cartas de amor en registros de transacciones, o contratos inteligentes que contengan 1,000,000 de dólares en la cadena, y 10 años después seguirá allí esperando que lo leas e interactúes. Para que las DApps se descentralicen completamente y eliminen las claves de actualización, necesitan estar seguras de que sus dependencias no se actualizarán de manera que las dañen, especialmente L1 en sí misma.
Si nos comprometemos a encontrar un equilibrio entre estas dos necesidades y a reducir o revertir la hinchazón, 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 útil muy larga. En ciertos casos, Ethereum ya ha tenido éxito: la prueba de trabajo ha desaparecido, el opcode SELFDESTRUCT ha desaparecido en su mayoría, y los nodos de la cadena de beacon 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.
El objetivo principal de The Purge:
Reduciendo o eliminando la necesidad de que cada nodo almacene permanentemente todos los registros históricos e incluso el estado final, se disminuyen los requisitos de almacenamiento del cliente.
Reducir la complejidad del protocolo eliminando funciones innecesarias
Expiración del historial
¿Qué problema resuelve?
Hasta el momento de escribir este artículo, un nodo de Ethereum completamente sincronizado necesita aproximadamente 1.1 TB de espacio en disco para ejecutar el cliente, además de necesitar cientos de GB de espacio en disco para el cliente de consenso. La gran mayoría 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 varios 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 está vinculado por hash a ( y a otras estructuras ) que apuntan al bloque anterior, alcanzar consenso sobre el bloque actual es suficiente para alcanzar consenso sobre la historia. Siempre que la red alcance consenso sobre el bloque más reciente, cualquier bloque histórico o 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 dicha prueba permite a cualquier otra persona verificar su corrección. El consenso es un modelo de confianza de N/2 de N, mientras que la historia es un modelo de confianza de N de N.
Esto nos ofrece muchas opciones sobre cómo almacenar registros históricos. 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 funcionado las redes de semillas durante décadas: aunque la red almacena y distribuye millones de archivos en total, cada participante almacena y distribuye solo unos pocos de esos archivos. Tal vez 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, podemos construir una red con 100,000 nodos, donde cada nodo almacena aleatoriamente el 10% de los registros históricos, entonces cada dato se replicará 10,000 veces - lo que es 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 de la modelo de almacenamiento permanente de todo el historial en todos los nodos. El bloque de consenso ( está relacionado con la parte del consenso de prueba de participación ) que solo almacena aproximadamente 6 meses. Blob solo almacena 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 el contenido, y luego establecer una red peer-to-peer compuesta por nodos de Ethereum que almacene datos antiguos de manera distribuida.
Los códigos de borrado se pueden usar para mejorar la robustez, manteniendo 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 en el blob.
¿cuáles son las conexiones 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 distribuidos de objetos SSZ en Portal
Cómo aumentar el límite de gas ( Paradigm )
¿Qué más se necesita hacer, qué se debe sopesar?
El trabajo principal restante incluye construir e integrar una solución distribuida concreta para almacenar el historial, al menos el historial de ejecución, pero que eventualmente también incluya consenso y blob. La solución más simple es ( i ) simplemente introducir una biblioteca de torrent existente, así como ( ii ) una solución nativa de Ethereum llamada Portal Network. Una vez que se introduzca cualquiera de estas, podremos activar el EIP-4444. El EIP-4444 en sí no requiere un hard fork, pero sí necesita una nueva versión del protocolo de red. Por lo tanto, es valioso habilitarlo para todos los clientes a la vez, de lo contrario, existe el riesgo de que los clientes fallen al conectarse a otros nodos esperando descargar el historial completo, pero en realidad no lo obtienen.
Las principales consideraciones 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 de archivo existentes y de varios proveedores centralizados para la copia. Esto es fácil, pero debilita la posición de Ethereum como un lugar de registro permanente. Un enfoque más difícil pero más seguro es construir e integrar primero una red torrent para almacenar el historial de manera distribuida. Aquí, "¿cuánto nos esforzamos?" tiene dos dimensiones:
¿Cómo nos esforzamos para asegurar que el conjunto de nodos más grande realmente almacene todos los datos?
¿Qué tan profunda es la integración del almacenamiento histórico en el protocolo?
Un enfoque extremadamente paranoico para ( implicaría la prueba de custodia: de hecho, requeriría que cada validador de prueba de participación almacene un cierto porcentaje de registros históricos y los verifique periódicamente de forma criptográfica para asegurarse de que lo están 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 involucra el trabajo que ya se ha completado hoy: el Portal ha almacenado un archivo ERA que contiene toda la historia de Ethereum. Una implementación más completa implicará conectarlo efectivamente 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, también pueda 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 ejecutar o iniciar nodos sea extremadamente fácil, entonces reducir los requisitos de almacenamiento histórico puede decirse que es 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 EIP-4444 se puede realizar la visión de ejecutar nodos de Ethereum en un smartwatch y configurarlos en solo unos minutos.
La limitación del almacenamiento histórico también hace que la implementación de nodos de Ethereum más nuevos sea más viable, ya que solo admiten la última versión del protocolo, lo que los hace más simples. Por ejemplo, ahora se pueden eliminar de forma segura muchas líneas de código, porque 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.
![Vitalik: El posible futuro de Ethereum, The Purge]###https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp(
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, ya que el estado continúa 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 a largo plazo impondrá una carga a 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 puede ser leído en cualquier momento por cualquier transacción. Si introducimos la falta de estado, algunos piensan que este problema tal vez 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 incluyen 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; al final, podríamos desear hacer que el estado expire para mantener la descentralización de Ethereum.
) ¿Qué es eso y 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. En cambio, lo que queremos es que el objeto expire automáticamente con el tiempo. El desafío clave es hacerlo de manera que se logren los tres objetivos:
Eficiencia: No se necesita una gran cantidad de cálculos adicionales para ejecutar el proceso de vencimiento.
Amigabilidad del usuario: si alguien entra en una cueva durante cinco años y regresa, no debería perder el acceso a ETH, ERC20, NFT, posiciones de 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 sea fácil resolver problemas. Por ejemplo, puede hacer que cada objeto de estado también almacene un contador de fecha de vencimiento. ) se puede extender la fecha de vencimiento 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 objetos de estado con fechas de vencimiento. Sin embargo, esto introduce requisitos computacionales adicionales ) e incluso necesidades de almacenamiento (, y definitivamente no puede satisfacer los requisitos de facilidad de uso. A los desarrolladores también les resulta difícil razonar sobre los casos límite en los que los valores de almacenamiento a veces se restablecen a cero. Si establece un temporizador de vencimiento dentro del alcance del contrato, eso técnicamente haría la vida más fácil para los desarrolladores, pero complicaría 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, incluyendo propuestas como "alquiler de blockchain" y "regeneración". Al final, combinamos las mejores partes de las propuestas y nos centramos en dos tipos de "soluciones conocidas como las menos malas":
Soluciones para el estado de expiración parcial
Sugerencia de vencimiento de estado basada en el ciclo de dirección
) Expiración parcial del estado
Algunas propuestas de estado vencidas siguen los mismos principios. Dividimos el estado en bloques. Cada persona almacena permanentemente un "mapeo de nivel 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 almacena.
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 ), aunque es compatible con cualquier forma de estado sin estado, como un á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 de hasta 256 * 31 = 7,936 bytes. En muchos casos, el encabezado y el código completos de la cuenta, así como muchos espacios de almacenamiento de claves, se almacenarán bajo el mismo tallo. Si los datos bajo el tallo dado no se leen ni se escriben en un período de 6 meses, ya no se almacenarán esos datos, sino que solo se almacenarán los 32 bytes de esos datos.
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.
14 me gusta
Recompensa
14
6
Compartir
Comentar
0/400
LadderToolGuy
· 08-01 17:23
¿Se atreven a borrar datos históricos?
Ver originalesResponder0
Ser_APY_2000
· 08-01 13:46
El Dios de la V realmente sabe cómo hacer las cosas.
Ver originalesResponder0
TrustlessMaximalist
· 07-29 18:30
Vitalik Buterin habla de manera muy sólida.
Ver originalesResponder0
ConfusedWhale
· 07-29 18:27
V神 sigue hablando de una manera tan profunda.
Ver originalesResponder0
hodl_therapist
· 07-29 18:17
Lo que dice el viejo V no está mal.
Ver originalesResponder0
MetaverseLandlord
· 07-29 18:06
¡El espacio de almacenamiento es demasiado caro, es mejor limpiarlo en lugar de acumularlo!
Ethereum The Purge: Soltar almacenamiento histórico simplificar protocolo mejorar sostenibilidad
El posible futuro de Ethereum: The Purge
Autor: Vitalik Buterin
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 de la historia deben ser almacenadas de forma permanente por todos los clientes y ser descargadas por cualquier nuevo cliente para sincronizarse completamente con la red. Esto provoca un aumento constante en la carga del cliente y el tiempo de sincronización, incluso si la capacidad de la cadena se mantiene constante.
Función del protocolo: añadir 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 a estas dos tendencias, reduciendo la complejidad y la expansión con el tiempo. Al mismo tiempo, debemos conservar una de las propiedades clave que hacen grande a la cadena de bloques: la persistencia. Puedes colocar NFT, cartas de amor en registros de transacciones, o contratos inteligentes que contengan 1,000,000 de dólares en la cadena, y 10 años después seguirá allí esperando que lo leas e interactúes. Para que las DApps se descentralicen completamente y eliminen las claves de actualización, necesitan estar seguras de que sus dependencias no se actualizarán de manera que las dañen, especialmente L1 en sí misma.
Si nos comprometemos a encontrar un equilibrio entre estas dos necesidades y a reducir o revertir la hinchazón, 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 útil muy larga. En ciertos casos, Ethereum ya ha tenido éxito: la prueba de trabajo ha desaparecido, el opcode SELFDESTRUCT ha desaparecido en su mayoría, y los nodos de la cadena de beacon 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.
El objetivo principal de The Purge:
Expiración del historial
¿Qué problema resuelve?
Hasta el momento de escribir este artículo, un nodo de Ethereum completamente sincronizado necesita aproximadamente 1.1 TB de espacio en disco para ejecutar el cliente, además de necesitar cientos de GB de espacio en disco para el cliente de consenso. La gran mayoría 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 varios 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 está vinculado por hash a ( y a otras estructuras ) que apuntan al bloque anterior, alcanzar consenso sobre el bloque actual es suficiente para alcanzar consenso sobre la historia. Siempre que la red alcance consenso sobre el bloque más reciente, cualquier bloque histórico o 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 dicha prueba permite a cualquier otra persona verificar su corrección. El consenso es un modelo de confianza de N/2 de N, mientras que la historia es un modelo de confianza de N de N.
Esto nos ofrece muchas opciones sobre cómo almacenar registros históricos. 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 funcionado las redes de semillas durante décadas: aunque la red almacena y distribuye millones de archivos en total, cada participante almacena y distribuye solo unos pocos de esos archivos. Tal vez 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, podemos construir una red con 100,000 nodos, donde cada nodo almacena aleatoriamente el 10% de los registros históricos, entonces cada dato se replicará 10,000 veces - lo que es 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 de la modelo de almacenamiento permanente de todo el historial en todos los nodos. El bloque de consenso ( está relacionado con la parte del consenso de prueba de participación ) que solo almacena aproximadamente 6 meses. Blob solo almacena 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 el contenido, y luego establecer una red peer-to-peer compuesta por nodos de Ethereum que almacene datos antiguos de manera distribuida.
Los códigos de borrado se pueden usar para mejorar la robustez, manteniendo 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 en el blob.
¿cuáles son las conexiones con la investigación existente?
¿Qué más se necesita hacer, qué se debe sopesar?
El trabajo principal restante incluye construir e integrar una solución distribuida concreta para almacenar el historial, al menos el historial de ejecución, pero que eventualmente también incluya consenso y blob. La solución más simple es ( i ) simplemente introducir una biblioteca de torrent existente, así como ( ii ) una solución nativa de Ethereum llamada Portal Network. Una vez que se introduzca cualquiera de estas, podremos activar el EIP-4444. El EIP-4444 en sí no requiere un hard fork, pero sí necesita una nueva versión del protocolo de red. Por lo tanto, es valioso habilitarlo para todos los clientes a la vez, de lo contrario, existe el riesgo de que los clientes fallen al conectarse a otros nodos esperando descargar el historial completo, pero en realidad no lo obtienen.
Las principales consideraciones 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 de archivo existentes y de varios proveedores centralizados para la copia. Esto es fácil, pero debilita la posición de Ethereum como un lugar de registro permanente. Un enfoque más difícil pero más seguro es construir e integrar primero una red torrent para almacenar el historial de manera distribuida. Aquí, "¿cuánto nos esforzamos?" tiene dos dimensiones:
¿Cómo nos esforzamos para asegurar que el conjunto de nodos más grande realmente almacene todos los datos?
¿Qué tan profunda es la integración del almacenamiento histórico en el protocolo?
Un enfoque extremadamente paranoico para ( implicaría la prueba de custodia: de hecho, requeriría que cada validador de prueba de participación almacene un cierto porcentaje de registros históricos y los verifique periódicamente de forma criptográfica para asegurarse de que lo están 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 involucra el trabajo que ya se ha completado hoy: el Portal ha almacenado un archivo ERA que contiene toda la historia de Ethereum. Una implementación más completa implicará conectarlo efectivamente 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, también pueda 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 ejecutar o iniciar nodos sea extremadamente fácil, entonces reducir los requisitos de almacenamiento histórico puede decirse que es 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 EIP-4444 se puede realizar la visión de ejecutar nodos de Ethereum en un smartwatch y configurarlos en solo unos minutos.
La limitación del almacenamiento histórico también hace que la implementación de nodos de Ethereum más nuevos sea más viable, ya que solo admiten la última versión del protocolo, lo que los hace más simples. Por ejemplo, ahora se pueden eliminar de forma segura muchas líneas de código, porque 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.
![Vitalik: El posible futuro de Ethereum, The Purge]###https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp(
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, ya que el estado continúa 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 a largo plazo impondrá una carga a 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 puede ser leído en cualquier momento por cualquier transacción. Si introducimos la falta de estado, algunos piensan que este problema tal vez 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 incluyen 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; al final, podríamos desear hacer que el estado expire para mantener la descentralización de Ethereum.
) ¿Qué es eso y 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. En cambio, lo que queremos es que el objeto expire automáticamente con el tiempo. El desafío clave es hacerlo de manera que se logren los tres objetivos:
Eficiencia: No se necesita una gran cantidad de cálculos adicionales para ejecutar el proceso de vencimiento.
Amigabilidad del usuario: si alguien entra en una cueva durante cinco años y regresa, no debería perder el acceso a ETH, ERC20, NFT, posiciones de 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 sea fácil resolver problemas. Por ejemplo, puede hacer que cada objeto de estado también almacene un contador de fecha de vencimiento. ) se puede extender la fecha de vencimiento 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 objetos de estado con fechas de vencimiento. Sin embargo, esto introduce requisitos computacionales adicionales ) e incluso necesidades de almacenamiento (, y definitivamente no puede satisfacer los requisitos de facilidad de uso. A los desarrolladores también les resulta difícil razonar sobre los casos límite en los que los valores de almacenamiento a veces se restablecen a cero. Si establece un temporizador de vencimiento dentro del alcance del contrato, eso técnicamente haría la vida más fácil para los desarrolladores, pero complicaría 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, incluyendo propuestas como "alquiler de blockchain" y "regeneración". Al final, combinamos las mejores partes de las propuestas y nos centramos en dos tipos de "soluciones conocidas como las menos malas":
) Expiración parcial del estado
Algunas propuestas de estado vencidas siguen los mismos principios. Dividimos el estado en bloques. Cada persona almacena permanentemente un "mapeo de nivel 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 almacena.
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 ), aunque es compatible con cualquier forma de estado sin estado, como un á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 de hasta 256 * 31 = 7,936 bytes. En muchos casos, el encabezado y el código completos de la cuenta, así como muchos espacios de almacenamiento de claves, se almacenarán bajo el mismo tallo. Si los datos bajo el tallo dado no se leen ni se escriben en un período de 6 meses, ya no se almacenarán esos datos, sino que solo se almacenarán los 32 bytes de esos datos.