Vitalik Buterin recientemente publicó una serie de artículos de discusión sobre el futuro del desarrollo de Ethereum, explorando desde la fusión, el aumento, el azote, el margen hasta la última fase de purificación. Estos artículos muestran la visión de Vitalik sobre el futuro desarrollo de la red principal de Ethereum y cómo abordar los problemas actuales que enfrenta.
El objetivo principal de la fase de purificación 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, y reducir la complejidad del protocolo al eliminar funciones innecesarias.
Historia vencida
La expiración histórica tiene como objetivo resolver el problema de que los nodos de Ethereum completamente sincronizados requieren una gran cantidad de espacio en disco. Actualmente, un cliente de ejecución necesita aproximadamente 1.1 TB de espacio en disco, y un cliente de consenso necesita varios cientos de GB. La mayor parte de esto son datos históricos de hace varios años.
La clave de la historia obsoleta es aprovechar las características del mecanismo de consenso; basta con alcanzar un consenso sobre el último bloque para verificar la validez de los datos históricos. Esto proporciona múltiples opciones para el almacenamiento de registros históricos, como que cada nodo almacene solo una parte de los datos.
Actualmente, Ethereum ha comenzado a desprenderse gradualmente del modelo en el que todos los nodos almacenan permanentemente toda la historia. Los bloques de consenso solo almacenan aproximadamente 6 meses, y los blobs solo almacenan aproximadamente 18 días. El objetivo futuro es establecer un período de almacenamiento unificado ( que podría ser de aproximadamente 18 días ), y luego almacenar datos antiguos a través de una red distribuida.
La implementación de la expiración histórica también requiere la construcción e integración de soluciones de almacenamiento distribuido específicas, como la introducción de bibliotecas torrent existentes o la red Portal nativa de Ethereum. La principal consideración es cómo esforzarse por proporcionar datos históricos "antiguos" y la profundidad de la integración del almacenamiento histórico en el protocolo.
La expiración del historial es crucial para la simplificación de la operación y el inicio de nodos, y ayuda a realizar la visión de ejecutar nodos de Ethereum en relojes inteligentes. También hace que los nodos de Ethereum más nuevos sean más viables, al soportar solo la última versión del protocolo.
Estado expirado
El estado expirado tiene como objetivo abordar el problema de que, incluso si se elimina la necesidad de almacenar el historial, la demanda de almacenamiento del cliente seguirá creciendo. Esto se debe a que el saldo de la cuenta del estado (, los números aleatorios, el código del contrato y el almacenamiento ) seguirán creciendo, y el usuario solo necesita pagar una tarifa única para cargar permanentemente al cliente con la carga de almacenamiento.
El estado de expiración es más difícil de lograr que la expiración histórica, ya que el diseño de EVM asume que los objetos de estado, una vez creados, existirán para siempre. Actualmente, hay dos tipos principales de soluciones: expiración de estado parcial y expiración de estado basada en ciclos de dirección.
Parte del estado caducado se divide en bloques, solo los datos que han sido accedidos recientemente se almacenan. EIP-7736 es una propuesta concreta que se basa en el diseño de "ramas y hojas" introducido para el árbol Verkle.
El diseño basado en ciclos de direcciones resuelve el problema de los conflictos de resurrección mediante una lista de árboles de estado en constante crecimiento. Cada período ( agrega un nuevo árbol de estado vacío una vez al año ), y los nodos completos solo almacenan los dos árboles más recientes.
El principal desafío de implementar el vencimiento del estado es la expansión o contracción del espacio de direcciones, lo que requiere resolver problemas complejos de compatibilidad y seguridad. Independientemente de si se implementa el vencimiento del estado, al final se deben abordar los problemas relacionados con el espacio de direcciones.
Limpieza de funciones
La limpieza de funciones tiene como objetivo reducir la complejidad del protocolo, mejorar la seguridad, la accesibilidad y la neutralidad confiable. Los métodos principales incluyen eliminar funciones innecesarias, simplificar los mecanismos existentes y unificar los formatos de datos.
Algunas oportunidades de simplificación específicas incluyen:
Convertir 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 Señales
Eliminar el orden de bytes mezclado
Mecanismo de Gas simplificado
Eliminar precompilado
Eliminar la observabilidad del gas
Mejora del análisis estático
La principal compensación de la simplificación de funciones es el grado de simplificación y velocidad en comparación con la compatibilidad hacia atrás. Es necesario establecer un canal estandarizado para realizar cambios que rompan la compatibilidad hacia atrás de manera no urgente, buscando un equilibrio entre la eliminación de características y la conservación.
El formato de objeto EVM ( EOF ) es un conjunto de cambios principales propuestos para el EVM, diseñado para permitir que el EVM se actualice de manera que tenga propiedades más robustas. Su ventaja es que crea un camino natural para agregar nuevas funcionalidades al EVM, pero también aumenta significativamente la complejidad del protocolo.
Una estrategia de simplificación más radical es transformar la mayor parte del contenido del protocolo en código de contrato, como convertir Ethereum L1 en solo la cadena de balizas, introduciendo una máquina virtual mínima que permita crear resúmenes. O intercambiar EVM en el lugar, eligiendo el nuevo "Ethereum VM oficial".
En general, la fase de purificación busca reducir la demanda de almacenamiento y la complejidad del protocolo a través de la expiración histórica, la expiración de estado y la limpieza de funciones, sentando las bases para la escalabilidad y sostenibilidad a largo plazo de Ethereum. Esto requiere buscar un equilibrio entre la simplificación y la compatibilidad, y puede implicar reformas profundas en el protocolo.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
9 me gusta
Recompensa
9
7
Compartir
Comentar
0/400
NFTragedy
· hace11h
¡Vender lo viejo es lo que permite avanzar!
Ver originalesResponder0
CryptoCross-TalkClub
· hace11h
Otra actualización, los tontos han sido tomados por tontos y los mineros también.
Ver originalesResponder0
TokenomicsTrapper
· hace11h
ngmi solo otra historia de cope de eth tbh...
Ver originalesResponder0
DegenDreamer
· hace11h
Otra vez hablando de simplificar, pero simplemente no sube.
Ver originalesResponder0
DaisyUnicorn
· hace11h
Vitalik Buterin va a podar el pequeño jardín de Ethereum~
Ver originalesResponder0
DogeBachelor
· hace11h
Actualizamos durante medio día y aún no sube el precio.
Camino a la purificación de Ethereum: Soltar la demanda de almacenamiento y simplificar la complejidad del protocolo
El posible futuro de Ethereum: purificación
Vitalik Buterin recientemente publicó una serie de artículos de discusión sobre el futuro del desarrollo de Ethereum, explorando desde la fusión, el aumento, el azote, el margen hasta la última fase de purificación. Estos artículos muestran la visión de Vitalik sobre el futuro desarrollo de la red principal de Ethereum y cómo abordar los problemas actuales que enfrenta.
El objetivo principal de la fase de purificación 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, y reducir la complejidad del protocolo al eliminar funciones innecesarias.
Historia vencida
La expiración histórica tiene como objetivo resolver el problema de que los nodos de Ethereum completamente sincronizados requieren una gran cantidad de espacio en disco. Actualmente, un cliente de ejecución necesita aproximadamente 1.1 TB de espacio en disco, y un cliente de consenso necesita varios cientos de GB. La mayor parte de esto son datos históricos de hace varios años.
La clave de la historia obsoleta es aprovechar las características del mecanismo de consenso; basta con alcanzar un consenso sobre el último bloque para verificar la validez de los datos históricos. Esto proporciona múltiples opciones para el almacenamiento de registros históricos, como que cada nodo almacene solo una parte de los datos.
Actualmente, Ethereum ha comenzado a desprenderse gradualmente del modelo en el que todos los nodos almacenan permanentemente toda la historia. Los bloques de consenso solo almacenan aproximadamente 6 meses, y los blobs solo almacenan aproximadamente 18 días. El objetivo futuro es establecer un período de almacenamiento unificado ( que podría ser de aproximadamente 18 días ), y luego almacenar datos antiguos a través de una red distribuida.
La implementación de la expiración histórica también requiere la construcción e integración de soluciones de almacenamiento distribuido específicas, como la introducción de bibliotecas torrent existentes o la red Portal nativa de Ethereum. La principal consideración es cómo esforzarse por proporcionar datos históricos "antiguos" y la profundidad de la integración del almacenamiento histórico en el protocolo.
La expiración del historial es crucial para la simplificación de la operación y el inicio de nodos, y ayuda a realizar la visión de ejecutar nodos de Ethereum en relojes inteligentes. También hace que los nodos de Ethereum más nuevos sean más viables, al soportar solo la última versión del protocolo.
Estado expirado
El estado expirado tiene como objetivo abordar el problema de que, incluso si se elimina la necesidad de almacenar el historial, la demanda de almacenamiento del cliente seguirá creciendo. Esto se debe a que el saldo de la cuenta del estado (, los números aleatorios, el código del contrato y el almacenamiento ) seguirán creciendo, y el usuario solo necesita pagar una tarifa única para cargar permanentemente al cliente con la carga de almacenamiento.
El estado de expiración es más difícil de lograr que la expiración histórica, ya que el diseño de EVM asume que los objetos de estado, una vez creados, existirán para siempre. Actualmente, hay dos tipos principales de soluciones: expiración de estado parcial y expiración de estado basada en ciclos de dirección.
Parte del estado caducado se divide en bloques, solo los datos que han sido accedidos recientemente se almacenan. EIP-7736 es una propuesta concreta que se basa en el diseño de "ramas y hojas" introducido para el árbol Verkle.
El diseño basado en ciclos de direcciones resuelve el problema de los conflictos de resurrección mediante una lista de árboles de estado en constante crecimiento. Cada período ( agrega un nuevo árbol de estado vacío una vez al año ), y los nodos completos solo almacenan los dos árboles más recientes.
El principal desafío de implementar el vencimiento del estado es la expansión o contracción del espacio de direcciones, lo que requiere resolver problemas complejos de compatibilidad y seguridad. Independientemente de si se implementa el vencimiento del estado, al final se deben abordar los problemas relacionados con el espacio de direcciones.
Limpieza de funciones
La limpieza de funciones tiene como objetivo reducir la complejidad del protocolo, mejorar la seguridad, la accesibilidad y la neutralidad confiable. Los métodos principales incluyen eliminar funciones innecesarias, simplificar los mecanismos existentes y unificar los formatos de datos.
Algunas oportunidades de simplificación específicas incluyen:
La principal compensación de la simplificación de funciones es el grado de simplificación y velocidad en comparación con la compatibilidad hacia atrás. Es necesario establecer un canal estandarizado para realizar cambios que rompan la compatibilidad hacia atrás de manera no urgente, buscando un equilibrio entre la eliminación de características y la conservación.
El formato de objeto EVM ( EOF ) es un conjunto de cambios principales propuestos para el EVM, diseñado para permitir que el EVM se actualice de manera que tenga propiedades más robustas. Su ventaja es que crea un camino natural para agregar nuevas funcionalidades al EVM, pero también aumenta significativamente la complejidad del protocolo.
Una estrategia de simplificación más radical es transformar la mayor parte del contenido del protocolo en código de contrato, como convertir Ethereum L1 en solo la cadena de balizas, introduciendo una máquina virtual mínima que permita crear resúmenes. O intercambiar EVM en el lugar, eligiendo el nuevo "Ethereum VM oficial".
En general, la fase de purificación busca reducir la demanda de almacenamiento y la complejidad del protocolo a través de la expiración histórica, la expiración de estado y la limpieza de funciones, sentando las bases para la escalabilidad y sostenibilidad a largo plazo de Ethereum. Esto requiere buscar un equilibrio entre la simplificación y la compatibilidad, y puede implicar reformas profundas en el protocolo.