Publicar

La comunidad de Ethereum propone reducir a 36 días el periodo de retención de bloques de la capa de consenso


La comunidad de Ethereum ha publicado una Propuesta de Mejora de Ethereum (EIP) clave destinada a reducir significativamente el periodo de retención de bloques de la capa de consenso, de aproximadamente 146 días a unos 36,4 días. Este cambio propuesto representa una modificación informativa que no requiere una bifurcación y que no necesita una actualización de la red ni una bifurcación dura para implementarse. La propuesta está diseñada para abordar el creciente desafío de la expansión de los datos de la blockchain, que ha impuesto exigencias de hardware cada vez mayores a los operadores de nodos. Al acortar el periodo de retención, la EIP pretende reducir significativamente el ancho de banda, el uso de disco y el tiempo necesarios para la recuperación de datos después de la sincronización con puntos de control, ayudando a preservar la descentralización de Ethereum al hacer más accesible la operación de nodos. Esta mejora técnica refleja los esfuerzos continuos por optimizar la infraestructura de Ethereum y mejorar la eficiencia operativa de los nodos.
Ver original
post-image
Esta página contiene contenido de terceros y no constituye ningún tipo de asesoramiento, ni implica que Gate respalde dichas opiniones. Para más información, consulta el aviso legal.
ETHETH-0,72%

  • 2

Añadir un comentario
Añadir un comentario

Comentar
SeedPhraseAmnesia
21/08/2026
Una modificación a nivel informativo que no requiere un fork suena a una optimización de bajo coste, pero ¿podrían los nodos antiguos tener problemas de compatibilidad al implementarla?
0Ver original
LiquidSniper
19/08/2026
Esta propuesta de 36 días es bastante práctica y reduce mucho la presión sobre el almacenamiento de los nodos, pero espero que la eficiencia de sincronización no se vea afectada.
0Ver original
OptionWave
19/08/2026
Que se reduzca el uso del disco es algo bueno, claro, pero al pasar de 146 días a 36 días, ¿no se volverá más complicado consultar los datos históricos? Los clientes ligeros y los nodos de archivo no deberían verse afectados, ¿verdad?
0Ver original
SpikeGuard
19/08/2026
Por fin alguien está atendiendo las necesidades de almacenamiento de los nodos completos; antes, sincronizar una vez requería descargar varios cientos de GB, lo que realmente desalentaba. Que haya más cambios así.
0Ver original
MacroScope
19/08/2026
Como operador de nodos, este cambio es genial: permite ahorrar bastante ancho de banda y espacio en disco, aunque no sé si tendrá efectos secundarios en el servicio de snapshots.
1Ver original
Ver más
DividendRetire
19/08/2026
Al reducir la ventana de retención a 36 días, mi primera reacción es: ¿quién se encargará de conservar los datos anteriores? ¿Significa que, en el futuro, solo podremos consultar los bloques antiguos mediante servicios de terceros?
1Ver original
Ver más
DepositBouncer
19/08/2026
La idea del EIP es bastante clara: intercambiar tiempo por espacio; total, después de sincronizar el checkpoint basta con recurrir al retroceso. Pero el requisito previo es que haya suficientes nodos de archivo en la red; de lo contrario, las lagunas en la información histórica serían problemáticas.
1Ver original
Ver más
TwoFactorZen
19/08/2026
Optimizar la infraestructura es algo positivo, pero no hay que convertir la descentralización en una dependencia de indexadores centralizados con tal de reducir las barreras de entrada; esperemos que haya soluciones complementarias más adelante.
1Ver original
Ver más
GasWizard
19/08/2026
Primera revisión
La diferencia entre 36 y 146 días es bastante grande; parece que están apostando a que todos harán sincronizaciones periódicas. Pero no han explicado los detalles técnicos, así que esperemos a ver qué se debate en la comunidad.
0Ver original
Ver más