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 aspectos: la acumulación de datos históricos y el aumento de las funciones del protocolo. Para que Ethereum pueda mantenerse a largo plazo, necesitamos ejercer una fuerte contracorriente contra estas dos tendencias, reduciendo la complejidad y la expansión a medida que pasa el tiempo. Al mismo tiempo, necesitamos preservar la persistencia de la blockchain como una propiedad clave.
El objetivo principal de The Purge es:
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.
History expiry historial de caducidad
El historial de registros tiene como objetivo resolver el problema del crecimiento continuo de las necesidades de almacenamiento de los nodos. Actualmente, un nodo de Ethereum completamente sincronizado requiere aproximadamente 1.1 TB de espacio en disco, y sigue aumentando cientos de GB cada año.
La idea básica de la expiración del historial es: cada nodo solo almacena los datos históricos completos de un período reciente de (, como 18 días ), mientras que los datos más antiguos son almacenados de manera distribuida por los nodos en la red. Esto se puede lograr de manera similar a las redes de semillas, donde cada nodo solo almacena una pequeña parte de los datos antiguos.
Actualmente se ha comenzado a implementar esta idea, como que los bloques de consenso solo almacenan alrededor de 6 meses, y los blobs solo almacenan alrededor de 18 días. La propuesta EIP-4444 introduce 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 ( que podría ser de aproximadamente 18 días ), después de lo cual una red P2P compuesta por nodos de Ethereum almacenará datos antiguos de manera distribuida.
La implementación del historial requiere más trabajo, como construir e integrar soluciones de almacenamiento distribuido específicas, y manejar la replicación de datos históricos antiguos, entre otros. La principal consideración es cómo nos esforzamos por asegurar que el conjunto de nodos más grande realmente almacene todos los datos, y cuán profunda es la integración del conjunto de almacenamiento histórico en el protocolo.
State expiry estado de expiración
El vencimiento del estado tiene como objetivo abordar el problema del crecimiento continuo del estado de Ethereum. Incluso si se elimina la necesidad de almacenar el historial, la demanda de almacenamiento de estado por parte del cliente seguirá creciendo aproximadamente 50 GB al año.
El desafío clave de la expiración del estado radica en cómo lograr la expiración automática de los objetos de estado mientras se mantiene la compatibilidad con EVM. Actualmente, hay principalmente dos tipos de soluciones:
Parte del estado expira: el estado se divide en bloques, y solo los bloques que se han accedido recientemente se almacenan. Una propuesta concreta es EIP-7736, que se basa en el diseño de "hoja y tallo" de los árboles Verkle, almacenando datos adyacentes bajo el mismo "tronco", y si no se accede en un plazo de 6 meses, solo se almacena un compromiso de 32 bytes.
Estado de vencimiento basado en el ciclo de direcciones: se utiliza una lista de árbol de estado en constante crecimiento, donde cada periodo (, como 1 año ), se añade un nuevo árbol vacío. Los nodos completos solo almacenan los dos árboles más recientes. Los objetos de estado vencidos pueden ser recuperados proporcionando una prueba.
Ambas soluciones enfrentan algunos desafíos, como el diseño de incentivos, los cambios en el formato de dirección, etc. Los caminos posibles en el futuro incluyen: realizar solo una desmaterialización sin expiración del estado, llevar a cabo una expiración parcial del estado, o realizar la expiración del estado mediante la expansión o contracción del espacio de direcciones. Es necesario sopesar la simplificación del protocolo con la compatibilidad hacia atrás.
Limpieza de características
La limpieza de características tiene como objetivo reducir la complejidad del protocolo eliminando funciones innecesarias. Algunas de las principales oportunidades de limpieza incluyen:
Convertir la codificación RLP a SSZ
Eliminar el tipo de transacción antiguo
Reformar el mecanismo LOG
Eliminar el 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
Simplificar el mecanismo de gas
Eliminar precompilados poco utilizados
Hacer que el gas no sea observable
Mejorar el análisis estático
Realizar esta limpieza requiere un equilibrio entre el grado de simplificación y la compatibilidad hacia atrás. Es necesario establecer un proceso estandarizado para realizar cambios no compatibles con versiones anteriores que no sean urgentes. El formato de objeto EVM (EOF) propone una serie de cambios, pero también aumenta la complejidad, lo que requiere un balance.
Una estrategia de simplificación más radical es convertir la mayor parte del contenido del protocolo en código de contrato, como transformar el EVM en un resumen, o reemplazar el EVM con una nueva máquina virtual. Esto puede simplificar significativamente el protocolo central, pero la dificultad de implementación es mayor.
En general, The Purge tiene como objetivo reducir la complejidad y los requisitos de almacenamiento de Ethereum a través de la expiración de registros históricos, la expiración de estados y la limpieza de características, para garantizar su sostenibilidad a largo plazo. Esto requiere un equilibrio entre la simplificación y la compatibilidad, y establecer un proceso ordenado y a largo plazo para implementar estos cambios.
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.
10 me gusta
Recompensa
10
7
Compartir
Comentar
0/400
RooftopReserver
· 07-25 09:20
Ay, finalmente V神 está dispuesto a limpiar la basura.
Ver originalesResponder0
DaoResearcher
· 07-25 03:50
La base de datos de referencia muestra que esta ruta presenta múltiples riesgos de fork.
Ver originalesResponder0
ContractTester
· 07-22 13:46
Limpiar el historial - Interesante, no es mejor limpiar el gas
Ver originalesResponder0
RegenRestorer
· 07-22 13:45
Organiza lo que tengas que organizar, no afectes el volumen de transacciones.
Ver originalesResponder0
MetaReckt
· 07-22 13:31
继续trampa呗
Ver originalesResponder0
TokenTherapist
· 07-22 13:26
¡Zan Bit acaba de terminar el desayuno, debería Gran aumento!
Ethereum El plan The Purge: Soltar la complejidad y asegurar la sostenibilidad a largo plazo
El posible futuro 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 aspectos: la acumulación de datos históricos y el aumento de las funciones del protocolo. Para que Ethereum pueda mantenerse a largo plazo, necesitamos ejercer una fuerte contracorriente contra estas dos tendencias, reduciendo la complejidad y la expansión a medida que pasa el tiempo. Al mismo tiempo, necesitamos preservar la persistencia de la blockchain como una propiedad clave.
El objetivo principal de The Purge es:
History expiry historial de caducidad
El historial de registros tiene como objetivo resolver el problema del crecimiento continuo de las necesidades de almacenamiento de los nodos. Actualmente, un nodo de Ethereum completamente sincronizado requiere aproximadamente 1.1 TB de espacio en disco, y sigue aumentando cientos de GB cada año.
La idea básica de la expiración del historial es: cada nodo solo almacena los datos históricos completos de un período reciente de (, como 18 días ), mientras que los datos más antiguos son almacenados de manera distribuida por los nodos en la red. Esto se puede lograr de manera similar a las redes de semillas, donde cada nodo solo almacena una pequeña parte de los datos antiguos.
Actualmente se ha comenzado a implementar esta idea, como que los bloques de consenso solo almacenan alrededor de 6 meses, y los blobs solo almacenan alrededor de 18 días. La propuesta EIP-4444 introduce 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 ( que podría ser de aproximadamente 18 días ), después de lo cual una red P2P compuesta por nodos de Ethereum almacenará datos antiguos de manera distribuida.
La implementación del historial requiere más trabajo, como construir e integrar soluciones de almacenamiento distribuido específicas, y manejar la replicación de datos históricos antiguos, entre otros. La principal consideración es cómo nos esforzamos por asegurar que el conjunto de nodos más grande realmente almacene todos los datos, y cuán profunda es la integración del conjunto de almacenamiento histórico en el protocolo.
State expiry estado de expiración
El vencimiento del estado tiene como objetivo abordar el problema del crecimiento continuo del estado de Ethereum. Incluso si se elimina la necesidad de almacenar el historial, la demanda de almacenamiento de estado por parte del cliente seguirá creciendo aproximadamente 50 GB al año.
El desafío clave de la expiración del estado radica en cómo lograr la expiración automática de los objetos de estado mientras se mantiene la compatibilidad con EVM. Actualmente, hay principalmente dos tipos de soluciones:
Parte del estado expira: el estado se divide en bloques, y solo los bloques que se han accedido recientemente se almacenan. Una propuesta concreta es EIP-7736, que se basa en el diseño de "hoja y tallo" de los árboles Verkle, almacenando datos adyacentes bajo el mismo "tronco", y si no se accede en un plazo de 6 meses, solo se almacena un compromiso de 32 bytes.
Estado de vencimiento basado en el ciclo de direcciones: se utiliza una lista de árbol de estado en constante crecimiento, donde cada periodo (, como 1 año ), se añade un nuevo árbol vacío. Los nodos completos solo almacenan los dos árboles más recientes. Los objetos de estado vencidos pueden ser recuperados proporcionando una prueba.
Ambas soluciones enfrentan algunos desafíos, como el diseño de incentivos, los cambios en el formato de dirección, etc. Los caminos posibles en el futuro incluyen: realizar solo una desmaterialización sin expiración del estado, llevar a cabo una expiración parcial del estado, o realizar la expiración del estado mediante la expansión o contracción del espacio de direcciones. Es necesario sopesar la simplificación del protocolo con la compatibilidad hacia atrás.
Limpieza de características
La limpieza de características tiene como objetivo reducir la complejidad del protocolo eliminando funciones innecesarias. Algunas de las principales oportunidades de limpieza incluyen:
Realizar esta limpieza requiere un equilibrio entre el grado de simplificación y la compatibilidad hacia atrás. Es necesario establecer un proceso estandarizado para realizar cambios no compatibles con versiones anteriores que no sean urgentes. El formato de objeto EVM (EOF) propone una serie de cambios, pero también aumenta la complejidad, lo que requiere un balance.
Una estrategia de simplificación más radical es convertir la mayor parte del contenido del protocolo en código de contrato, como transformar el EVM en un resumen, o reemplazar el EVM con una nueva máquina virtual. Esto puede simplificar significativamente el protocolo central, pero la dificultad de implementación es mayor.
En general, The Purge tiene como objetivo reducir la complejidad y los requisitos de almacenamiento de Ethereum a través de la expiración de registros históricos, la expiración de estados y la limpieza de características, para garantizar su sostenibilidad a largo plazo. Esto requiere un equilibrio entre la simplificación y la compatibilidad, y establecer un proceso ordenado y a largo plazo para implementar estos cambios.