El camino hacia un Ethereum más simple y eficiente
Un gran desafío que enfrenta Ethereum es cómo reducir la complejidad y los requerimientos de almacenamiento a largo plazo, manteniendo al mismo tiempo la persistencia de la blockchain y sus características de descentralización. Esto requiere que tomemos medidas en varios ámbitos clave:
Registro histórico expirado
Actualmente, un nodo de Ethereum completamente sincronizado necesita aproximadamente 1.1TB de espacio de almacenamiento, la mayor parte de la cual se utiliza para almacenar datos históricos. Incluso si el límite de gas se mantiene constante, el tamaño del nodo seguirá aumentando en cientos de GB cada año.
La solución es establecer una red punto a punto compuesta por nodos de Ethereum para almacenar datos antiguos de manera distribuida. Cada nodo solo necesita almacenar datos de aproximadamente los últimos 18 días, y los datos más antiguos se pueden obtener a través de la red. Esto puede reducir significativamente la carga de almacenamiento de un solo nodo.
El trabajo principal para implementar la expiración del historial incluye:
Construir e integrar soluciones de almacenamiento distribuido específicas, como la introducción de bibliotecas torrent existentes o la red Portal nativa de Ethereum.
Habilitar EIP-4444, limitar el tiempo que los nodos almacenan datos históricos.
Decidir cómo manejar los datos históricos "antiguos", si depender completamente de los nodos de archivo existentes o construir una red de almacenamiento distribuido más robusta.
Estado expirado
Incluso si se elimina la necesidad de almacenar el historial, la demanda de almacenamiento del cliente seguirá creciendo aproximadamente 50 GB cada año, ya que el saldo de la cuenta de estado (, el código del contrato, etc. ) siguen en aumento.
Hay dos tipos principales de soluciones:
Estado parcial expirado: dividir el estado en bloques, almacenar solo los bloques de datos que se han accedido recientemente, los demás datos solo guardar un compromiso de 32 bytes.
Expiración de estado basada en el ciclo de dirección: se agregan periódicamente nuevos árboles de estado vacíos, y el árbol antiguo se congela. Los nodos completos solo almacenan los dos árboles más recientes.
Ambas soluciones tienen sus ventajas y desventajas, y es necesario equilibrar entre complejidad, facilidad de uso y amigabilidad para los desarrolladores. Cualquiera de las soluciones que se elija, es necesario abordar el problema de la expansión o contracción del espacio de direcciones, lo cual es un enorme desafío en sí mismo.
Limpieza de funciones
Para reducir la complejidad del protocolo, necesitamos eliminar algunas funciones innecesarias o poco utilizadas:
Reemplazar completamente la codificación RLP por SSZ
Eliminar el tipo de transacción antiguo
Mecanismo de registro simplificado
Eliminar el mecanismo del comité de sincronización de la cadena de balizas
Formato de datos unificado
Simplificación del mecanismo de gas
Eliminar algunas precompilaciones
Cancelar la observabilidad del gas
Mejorar la capacidad de análisis estático
Al realizar estas simplificaciones, es necesario sopesar el grado de simplificación/velocidad con la compatibilidad hacia atrás. Se debe establecer un proceso estandarizado para manejar los cambios incompatibles con la versión anterior que no sean urgentes.
Un enfoque más radical de simplificación es transformar la mayor parte del contenido del protocolo en código de contrato. Por ejemplo, simplificar Ethereum L1 para que solo contenga la cadena de balizas, introducir una máquina virtual mínima, y luego reconstruir la EVM sobre ella como el primer resumen. Este método puede simplificar considerablemente el protocolo, pero su implementación es bastante difícil.
En general, a través de estas medidas, podemos reducir significativamente su complejidad y requisitos de almacenamiento, manteniendo al mismo tiempo el valor fundamental de Ethereum, estableciendo así las bases para un desarrollo sostenible a largo plazo. Esto requiere un esfuerzo conjunto de la comunidad para encontrar un equilibrio entre la innovación tecnológica y la compatibilidad hacia atrás.
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.
5 me gusta
Recompensa
5
7
Compartir
Comentar
0/400
GraphGuru
· hace5h
¿Qué hacer si no tengo dinero para mejorar la máquina?
Ver originalesResponder0
failed_dev_successful_ape
· hace5h
Vaya, ajustes tan grandes.
Ver originalesResponder0
DoomCanister
· hace5h
Sigue oliendo mal y todo estará bien.
Ver originalesResponder0
DeFiVeteran
· hace5h
El desarrollo tecnológico debe ser sólido.
Ver originalesResponder0
BridgeTrustFund
· hace5h
La actualización de la Mainnet debe hacerse poco a poco.
Ver originalesResponder0
Token_Sherpa
· hace5h
jaja otro roadmap de "optimización"... espero que no sea solo ponzinomía disfrazada
Hoja de ruta para el desarrollo a largo plazo de Ethereum: optimización del almacenamiento, simplificación del protocolo, mejora de la eficiencia
El camino hacia un Ethereum más simple y eficiente
Un gran desafío que enfrenta Ethereum es cómo reducir la complejidad y los requerimientos de almacenamiento a largo plazo, manteniendo al mismo tiempo la persistencia de la blockchain y sus características de descentralización. Esto requiere que tomemos medidas en varios ámbitos clave:
Registro histórico expirado
Actualmente, un nodo de Ethereum completamente sincronizado necesita aproximadamente 1.1TB de espacio de almacenamiento, la mayor parte de la cual se utiliza para almacenar datos históricos. Incluso si el límite de gas se mantiene constante, el tamaño del nodo seguirá aumentando en cientos de GB cada año.
La solución es establecer una red punto a punto compuesta por nodos de Ethereum para almacenar datos antiguos de manera distribuida. Cada nodo solo necesita almacenar datos de aproximadamente los últimos 18 días, y los datos más antiguos se pueden obtener a través de la red. Esto puede reducir significativamente la carga de almacenamiento de un solo nodo.
El trabajo principal para implementar la expiración del historial incluye:
Construir e integrar soluciones de almacenamiento distribuido específicas, como la introducción de bibliotecas torrent existentes o la red Portal nativa de Ethereum.
Habilitar EIP-4444, limitar el tiempo que los nodos almacenan datos históricos.
Decidir cómo manejar los datos históricos "antiguos", si depender completamente de los nodos de archivo existentes o construir una red de almacenamiento distribuido más robusta.
Estado expirado
Incluso si se elimina la necesidad de almacenar el historial, la demanda de almacenamiento del cliente seguirá creciendo aproximadamente 50 GB cada año, ya que el saldo de la cuenta de estado (, el código del contrato, etc. ) siguen en aumento.
Hay dos tipos principales de soluciones:
Estado parcial expirado: dividir el estado en bloques, almacenar solo los bloques de datos que se han accedido recientemente, los demás datos solo guardar un compromiso de 32 bytes.
Expiración de estado basada en el ciclo de dirección: se agregan periódicamente nuevos árboles de estado vacíos, y el árbol antiguo se congela. Los nodos completos solo almacenan los dos árboles más recientes.
Ambas soluciones tienen sus ventajas y desventajas, y es necesario equilibrar entre complejidad, facilidad de uso y amigabilidad para los desarrolladores. Cualquiera de las soluciones que se elija, es necesario abordar el problema de la expansión o contracción del espacio de direcciones, lo cual es un enorme desafío en sí mismo.
Limpieza de funciones
Para reducir la complejidad del protocolo, necesitamos eliminar algunas funciones innecesarias o poco utilizadas:
Al realizar estas simplificaciones, es necesario sopesar el grado de simplificación/velocidad con la compatibilidad hacia atrás. Se debe establecer un proceso estandarizado para manejar los cambios incompatibles con la versión anterior que no sean urgentes.
Un enfoque más radical de simplificación es transformar la mayor parte del contenido del protocolo en código de contrato. Por ejemplo, simplificar Ethereum L1 para que solo contenga la cadena de balizas, introducir una máquina virtual mínima, y luego reconstruir la EVM sobre ella como el primer resumen. Este método puede simplificar considerablemente el protocolo, pero su implementación es bastante difícil.
En general, a través de estas medidas, podemos reducir significativamente su complejidad y requisitos de almacenamiento, manteniendo al mismo tiempo el valor fundamental de Ethereum, estableciendo así las bases para un desarrollo sostenible a largo plazo. Esto requiere un esfuerzo conjunto de la comunidad para encontrar un equilibrio entre la innovación tecnológica y la compatibilidad hacia atrás.