Un desafío importante que enfrenta Ethereum es cómo reducir la complejidad y las demandas de almacenamiento a largo plazo, al mismo tiempo que se mantiene la persistencia y la descentralización de la cadena. Para que Ethereum pueda mantenerse a largo plazo, necesitamos ejercer una fuerte presión contraria sobre la complejidad y la expansión, reduciendo la complejidad y la expansión con el tiempo. Pero, al mismo tiempo, necesitamos conservar la persistencia de la cadena de bloques como una propiedad clave.
Los principales objetivos de la purificación incluyen:
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.
Registro histórico expirado
¿Qué problema resuelve?
Hasta ahora, 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 para el cliente de consenso. La gran mayoría de estos son datos históricos, y aunque el tamaño del bloque no cambie, el tamaño del nodo seguirá aumentando en varios cientos de GB cada año.
¿Qué es y cómo funciona?
Una característica clave que simplifica el problema del almacenamiento histórico es que, dado que cada bloque está vinculado al bloque anterior a través de un hash, basta con alcanzar un consenso sobre el actual para alcanzar un consenso sobre la historia. Esto nos ofrece muchas opciones sobre cómo almacenar registros históricos. Una opción natural es una red en la que cada nodo almacena solo una pequeña parte de los datos.
Hoy en día, Ethereum ha comenzado a deshacerse del modelo en el que todos los nodos almacenan permanentemente toda la historia. Los bloques de consenso solo almacenan aproximadamente 6 meses. Los blobs solo almacenan aproximadamente 18 días. EIP-4444 tiene como objetivo introducir un período de almacenamiento de un año para los bloques históricos y los recibos. El objetivo a largo plazo es establecer un período unificado ( que puede 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.
¿Qué más se necesita hacer, qué se debe considerar?
El trabajo principal restante incluye la construcción e integración de una solución distribuida concreta para almacenar el historial. La solución más simple es introducir una biblioteca torrent existente o una solución nativa de Ethereum llamada red Portal. La principal compensación implica cómo nos esforzamos por proporcionar datos históricos "antiguos". La solución más simple es dejar de almacenar historia antigua mañana y depender de nodos de archivo existentes y varios proveedores centralizados para la replicación. Un camino más difícil pero más seguro es construir e integrar primero una red torrent para almacenar el historial de manera distribuida.
¿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 los requisitos de almacenamiento histórico puede decirse que es más importante que la falta de estado. 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.
Estado de vencimiento
¿Qué problema resuelve?
Incluso si eliminamos la necesidad de que los clientes almacenen el historial, la demanda de almacenamiento de los clientes seguirá creciendo, alrededor de 50 GB por año, ya que el estado continúa creciendo. Los usuarios pueden pagar una tarifa única, lo que les impone una carga a los clientes de Ethereum tanto actuales como futuros.
¿Qué es y cómo funciona?
Hoy, al crear un nuevo objeto de estado, ese objeto de estado permanece en ese estado para siempre. Por el contrario, lo que queremos es que el objeto caduque automáticamente con el tiempo. El desafío clave es lograr esto de una manera que cumpla con los objetivos de eficiencia, facilidad de uso y amigabilidad para los desarrolladores.
Actualmente hay dos tipos de "soluciones que no son las peores conocidas":
Soluciones para el vencimiento de ciertos estados
Sugerencia de expiración de estado basada en el ciclo de direcciones
Las propuestas de estado que están a punto de expirar dividirán el estado en bloques. Cada persona almacena permanentemente un "mapeo superior", donde los bloques pueden estar vacíos o no. Los datos en cada bloque solo se almacenarán si se ha accedido a esos datos recientemente. Hay un mecanismo de "resurrección" si los datos ya no se almacenan.
El diseño basado en el ciclo de direcciones utiliza una lista de árboles de estado en constante crecimiento, y cualquier estado leído o escrito se guarda en el árbol de estado más reciente. Cada período (, por ejemplo: se añade un nuevo árbol de estado vacío una vez al año ). Los árboles antiguos quedan congelados. Los nodos completos solo almacenan los dos árboles más recientes.
¿Qué más se necesita hacer, qué se debe sopesar?
Creo que en el futuro hay cuatro caminos viables:
Hacemos que sea sin estado y nunca introducimos el estado de expiración.
Llevamos a cabo el vencimiento parcial de estados y aceptamos una tasa de crecimiento del tamaño del estado permanente que es mucho más baja pero aún no cero.
Realizamos la expiración de estado mediante la expansión del espacio de direcciones.
Realizamos la expiración del estado a través de la contracción del espacio de direcciones.
Un punto importante es que, independientemente de si se implementa o no un plan de vencimiento de estado que dependa de un cambio en el formato de dirección, al final debe resolverse el problema de la expansión y contracción del espacio de direcciones.
Limpieza de funciones
¿Qué problema resuelve?
Una de las condiciones previas clave para la seguridad, accesibilidad y neutralidad de confianza es la simplicidad. Si un protocolo es atractivo y simple, se reduce la posibilidad de cometer errores. Aumenta las oportunidades para que nuevos desarrolladores puedan participar en cualquier parte. Es más probable que sea justo y también más fácil de resistir a intereses especiales. Desafortunadamente, los protocolos, como cualquier sistema social, tienden a volverse más complejos con el tiempo por defecto.
¿Qué es y cómo funciona?
No hay ninguna solución única importante que pueda reducir la complejidad del protocolo; la naturaleza del problema es que hay muchas pequeñas soluciones. Algunos ejemplos clave incluyen:
Conversión de RLP a SSZ
Eliminar el tipo de transacción antiguo
LOG reforma
Eliminación final del mecanismo del comité de sincronización de la cadena de balizas
Formato de datos unificado
Eliminar el comité de la cadena de balizas
Eliminar el orden de bytes mezclado
Simplificación del mecanismo de Gas
Eliminar la precompilación
Eliminar la observabilidad del gas
Mejora del análisis estático
¿Qué más necesita hacerse, qué hay que sopesar?
La principal compensación de simplificar esta funcionalidad es el grado y la velocidad de nuestra simplificación frente a la compatibilidad hacia atrás. Un problema social más amplio es crear un canal estandarizado para realizar cambios que rompan la compatibilidad hacia atrás de manera no urgente.
El formato de objeto EVM ( EOF ) es un conjunto de cambios principales propuestos para EVM. Su ventaja es que crea un camino natural para agregar nuevas funciones de EVM y fomenta la migración a un EVM más estricto con mayores garantías. Su desventaja es el aumento significativo de la complejidad del protocolo, a menos que podamos encontrar una manera de eventualmente descontinuar y eliminar el antiguo EVM.
Una estrategia de simplificación de Ethereum más radical es mantener el protocolo sin cambios, pero trasladar la mayor parte de su funcionalidad del protocolo al código del contrato. La versión más extrema es hacer que Ethereum L1 sea "técnicamente" solo una cadena de balizas e introducir una máquina virtual mínima que permita a otros crear sus propios resúmenes. Luego, EVM se convertirá en el primero de estos resúmenes.
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.
16 me gusta
Recompensa
16
4
Compartir
Comentar
0/400
SchroedingersFrontrun
· hace17h
La optimización del almacenamiento es muy necesaria.
La ruta de purificación de Ethereum: el desafío a largo plazo de Soltar la complejidad y los requisitos de almacenamiento.
El posible futuro de Ethereum: purificación
Un desafío importante que enfrenta Ethereum es cómo reducir la complejidad y las demandas de almacenamiento a largo plazo, al mismo tiempo que se mantiene la persistencia y la descentralización de la cadena. Para que Ethereum pueda mantenerse a largo plazo, necesitamos ejercer una fuerte presión contraria sobre la complejidad y la expansión, reduciendo la complejidad y la expansión con el tiempo. Pero, al mismo tiempo, necesitamos conservar la persistencia de la cadena de bloques como una propiedad clave.
Los principales objetivos de la purificación incluyen:
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.
Registro histórico expirado
¿Qué problema resuelve?
Hasta ahora, 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 para el cliente de consenso. La gran mayoría de estos son datos históricos, y aunque el tamaño del bloque no cambie, el tamaño del nodo seguirá aumentando en varios cientos de GB cada año.
¿Qué es y cómo funciona?
Una característica clave que simplifica el problema del almacenamiento histórico es que, dado que cada bloque está vinculado al bloque anterior a través de un hash, basta con alcanzar un consenso sobre el actual para alcanzar un consenso sobre la historia. Esto nos ofrece muchas opciones sobre cómo almacenar registros históricos. Una opción natural es una red en la que cada nodo almacena solo una pequeña parte de los datos.
Hoy en día, Ethereum ha comenzado a deshacerse del modelo en el que todos los nodos almacenan permanentemente toda la historia. Los bloques de consenso solo almacenan aproximadamente 6 meses. Los blobs solo almacenan aproximadamente 18 días. EIP-4444 tiene como objetivo introducir un período de almacenamiento de un año para los bloques históricos y los recibos. El objetivo a largo plazo es establecer un período unificado ( que puede 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.
¿Qué más se necesita hacer, qué se debe considerar?
El trabajo principal restante incluye la construcción e integración de una solución distribuida concreta para almacenar el historial. La solución más simple es introducir una biblioteca torrent existente o una solución nativa de Ethereum llamada red Portal. La principal compensación implica cómo nos esforzamos por proporcionar datos históricos "antiguos". La solución más simple es dejar de almacenar historia antigua mañana y depender de nodos de archivo existentes y varios proveedores centralizados para la replicación. Un camino más difícil pero más seguro es construir e integrar primero una red torrent para almacenar el historial de manera distribuida.
¿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 los requisitos de almacenamiento histórico puede decirse que es más importante que la falta de estado. 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.
Estado de vencimiento
¿Qué problema resuelve?
Incluso si eliminamos la necesidad de que los clientes almacenen el historial, la demanda de almacenamiento de los clientes seguirá creciendo, alrededor de 50 GB por año, ya que el estado continúa creciendo. Los usuarios pueden pagar una tarifa única, lo que les impone una carga a los clientes de Ethereum tanto actuales como futuros.
¿Qué es y cómo funciona?
Hoy, al crear un nuevo objeto de estado, ese objeto de estado permanece en ese estado para siempre. Por el contrario, lo que queremos es que el objeto caduque automáticamente con el tiempo. El desafío clave es lograr esto de una manera que cumpla con los objetivos de eficiencia, facilidad de uso y amigabilidad para los desarrolladores.
Actualmente hay dos tipos de "soluciones que no son las peores conocidas":
Las propuestas de estado que están a punto de expirar dividirán el estado en bloques. Cada persona almacena permanentemente un "mapeo superior", donde los bloques pueden estar vacíos o no. Los datos en cada bloque solo se almacenarán si se ha accedido a esos datos recientemente. Hay un mecanismo de "resurrección" si los datos ya no se almacenan.
El diseño basado en el ciclo de direcciones utiliza una lista de árboles de estado en constante crecimiento, y cualquier estado leído o escrito se guarda en el árbol de estado más reciente. Cada período (, por ejemplo: se añade un nuevo árbol de estado vacío una vez al año ). Los árboles antiguos quedan congelados. Los nodos completos solo almacenan los dos árboles más recientes.
¿Qué más se necesita hacer, qué se debe sopesar?
Creo que en el futuro hay cuatro caminos viables:
Un punto importante es que, independientemente de si se implementa o no un plan de vencimiento de estado que dependa de un cambio en el formato de dirección, al final debe resolverse el problema de la expansión y contracción del espacio de direcciones.
Limpieza de funciones
¿Qué problema resuelve?
Una de las condiciones previas clave para la seguridad, accesibilidad y neutralidad de confianza es la simplicidad. Si un protocolo es atractivo y simple, se reduce la posibilidad de cometer errores. Aumenta las oportunidades para que nuevos desarrolladores puedan participar en cualquier parte. Es más probable que sea justo y también más fácil de resistir a intereses especiales. Desafortunadamente, los protocolos, como cualquier sistema social, tienden a volverse más complejos con el tiempo por defecto.
¿Qué es y cómo funciona?
No hay ninguna solución única importante que pueda reducir la complejidad del protocolo; la naturaleza del problema es que hay muchas pequeñas soluciones. Algunos ejemplos clave incluyen:
¿Qué más necesita hacerse, qué hay que sopesar?
La principal compensación de simplificar esta funcionalidad es el grado y la velocidad de nuestra simplificación frente a la compatibilidad hacia atrás. Un problema social más amplio es crear un canal estandarizado para realizar cambios que rompan la compatibilidad hacia atrás de manera no urgente.
El formato de objeto EVM ( EOF ) es un conjunto de cambios principales propuestos para EVM. Su ventaja es que crea un camino natural para agregar nuevas funciones de EVM y fomenta la migración a un EVM más estricto con mayores garantías. Su desventaja es el aumento significativo de la complejidad del protocolo, a menos que podamos encontrar una manera de eventualmente descontinuar y eliminar el antiguo EVM.
Una estrategia de simplificación de Ethereum más radical es mantener el protocolo sin cambios, pero trasladar la mayor parte de su funcionalidad del protocolo al código del contrato. La versión más extrema es hacer que Ethereum L1 sea "técnicamente" solo una cadena de balizas e introducir una máquina virtual mínima que permita a otros crear sus propios resúmenes. Luego, EVM se convertirá en el primero de estos resúmenes.