- Tema
7k Popularidad
10k Popularidad
4k Popularidad
30k Popularidad
362 Popularidad
97k Popularidad
27k Popularidad
27k Popularidad
7k Popularidad
15k Popularidad
- Anclado
7k Popularidad
10k Popularidad
4k Popularidad
30k Popularidad
362 Popularidad
97k Popularidad
27k Popularidad
27k Popularidad
7k Popularidad
15k Popularidad
El futuro desarrollo de Ethereum: The Purge tiene como objetivo simplificar el protocolo Soltar los requisitos de almacenamiento.
Futuro posible de Ethereum: The Purge
Desde el 14 de octubre, el fundador de Ethereum, Vitalik Buterin, ha publicado una serie de artículos de discusión sobre el futuro desarrollo de Ethereum, desde "The Merge" hasta el más reciente "The Purge", mostrando su visión sobre el futuro desarrollo de la red principal de Ethereum y las soluciones a los problemas actuales.
El artículo "The Purge" explora cómo Ethereum puede reducir la complejidad y los requisitos de almacenamiento a largo plazo, al tiempo que mantiene la persistencia y descentralización de la cadena. Las principales medidas incluyen la reducción de la carga de almacenamiento del cliente a través de "caducidad histórica" y "caducidad de estado", y la simplificación del protocolo mediante "limpieza de características" para garantizar la sostenibilidad y escalabilidad de la red.
History expiry historial de caducidad
¿Qué problema resuelve?
Actualmente, un nodo de Ethereum completamente sincronizado necesita aproximadamente 1.1TB de espacio en disco para ejecutar el cliente, además de varios cientos de GB para el cliente de consenso. La mayor parte son datos históricos, incluso si el límite de Gas no cambia, el tamaño del nodo seguirá aumentando varios cientos de GB cada año.
¿Qué es y cómo funciona?
Una característica clave del almacenamiento histórico es que alcanzar un consenso actual es suficiente para alcanzar un consenso histórico. Esto proporciona múltiples opciones para almacenar registros históricos, como redes donde cada nodo solo almacena parte de los datos.
Ethereum ha comenzado a alejarse del modelo de almacenamiento permanente de todo el historial en todos los nodos. Los bloques de consenso solo almacenan aproximadamente 6 meses, y 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 de almacenamiento unificado de aproximadamente 18 días, y luego establecer una red P2P compuesta por nodos de Ethereum para almacenar 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. La solución más sencilla podría ser reutilizar el código de borrado existente de Blob y también incluir los datos de ejecución y consenso en el blob.
¿Qué más necesita hacerse y qué se debe sopesar?
Los trabajos principales incluyen construir e integrar una solución distribuida concreta para almacenar el historial. La solución más sencilla es introducir una biblioteca torrent existente o una solución nativa de Ethereum llamada Portal Network.
Las principales consideraciones implican cómo esforzarse por proporcionar datos históricos "antiguos". La solución más simple es dejar de almacenar inmediatamente la historia antigua, confiando en los nodos de archivo existentes. La solución más segura pero más complicada es construir e integrar primero una red torrent.
y la interacción con otras partes del mapa de ruta
Reducir la demanda de almacenamiento histórico es crucial para facilitar enormemente la operación de nodos. Solo al lograr la falta de estado y EIP-4444 se podrá realizar la visión de ejecutar nodos de Ethereum en relojes inteligentes.
La limitación del almacenamiento histórico también hace que sea más viable para los nuevos nodos de Ethereum que solo soportan la última versión del protocolo, simplificando así el cliente.
State expiry estado de expiración
¿Qué problema resuelve?
Incluso si se eliminan las demandas de almacenamiento de historial, las demandas de almacenamiento del cliente seguirán aumentando aproximadamente 50GB por año, ya que el saldo de cuentas del estado (, el código de contrato, etc. ) seguirán creciendo. Los usuarios pueden pagar una sola vez, lo que implica una carga permanente para los clientes actuales y futuros.
¿Qué es y cómo funciona?
El estado es más difícil de "expirar" que la historia, porque el EVM asume que los objetos de estado existen para siempre una vez creados. El objetivo es permitir que los objetos expiren automáticamente con el tiempo, manteniendo a la vez la eficiencia, la facilidad de uso y la amigabilidad para los desarrolladores.
Principalmente hay dos tipos de soluciones:
Estado de expiración parcial: dividir el estado en bloques y solo almacenar los datos accedidos recientemente. EIP-7736 propone un esquema basado en árboles Verkle, donde los datos no accedidos en 6 meses solo almacenan un tronco de 32 bytes.
Expiración del estado basado en el ciclo de direcciones: se utiliza una lista de árboles de estado en constante crecimiento, añadiendo nuevos árboles vacíos cada año. Los nodos completos solo almacenan los dos árboles más recientes. Los datos caducados requieren pruebas para poder ser leídos y escritos.
¿Qué más se necesita hacer, qué se debe ponderar?
Los posibles caminos en el futuro incluyen:
Implementar sin estado, sin introducir la expiración del estado. El estado continúa creciendo pero solo necesita almacenamiento especial para usuarios.
Implementar un vencimiento parcial del estado, aceptando una tasa de crecimiento permanente baja pero no cero.
Implementar la expiración del estado a través de la expansión del espacio de direcciones. Se necesita un proceso de varios años para garantizar que la conversión del formato de dirección sea segura y efectiva.
Lograr la expiración del estado mediante la contracción del espacio de direcciones. Se requiere un proceso de varios años para garantizar la resolución de todos los riesgos de seguridad.
Independientemente de la solución adoptada, es necesario resolver el problema de la expansión y contracción del espacio de direcciones, ya que los ataques de colisión de direcciones se volverán más fáciles en el futuro.
Feature cleanup limpieza de características
¿Qué problema resuelve?
La simplicidad del protocolo es clave para la seguridad, accesibilidad y neutralidad de confianza. Sin embargo, los protocolos por defecto tienden a volverse más complejos con el tiempo. Necesitamos la capacidad de eliminar funciones y reducir la complejidad.
¿Qué es y cómo funciona?
No hay una única solución importante que pueda reducir la complejidad del protocolo, sino que se requieren muchas pequeñas soluciones. Algunos ejemplos clave incluyen:
Ejemplos en EVM:
¿Qué más se necesita hacer, qué se necesita sopesar?
La principal consideración es el nivel de simplificación y velocidad frente a la compatibilidad hacia atrás. Es necesario crear un proceso estandarizado para realizar cambios que rompan la compatibilidad hacia atrás que no sean urgentes, incluidos pasos como el análisis del impacto, la depreciación formal de EIP y la eliminación final.
El formato de objeto EVM ( EOF ) propone una serie de cambios en EVM, con el objetivo de permitir más actualizaciones. Es necesario sopesar la complejidad añadida con el objetivo de simplificar todo EVM.
Un enfoque más radical es convertir la mayor parte del contenido del protocolo en código de contrato, como transformar la EVM en un resumen o reemplazar la EVM con una nueva VM. Esto puede simplificar considerablemente el protocolo, pero requiere un equilibrio en la compatibilidad.