La poda de datos históricos asociada a EIP-4444 reduce las exigencias de almacenamiento de los nodos de Ethereum y, según Crypto Briefing, puede llevar la sincronización a menos de medio día. El cambio no elimina los nodos de archivo: redefine qué historia debe conservar cada nodo completo.
***

• EIP-4444 permite que clientes de ejecución descarten datos históricos anteriores a la Fusión y recorten entre 300 y 500 GB de almacenamiento.
• El plazo de retención pasó de unas 33.000 a cerca de 82.000 épocas, aproximadamente un año, mientras los nuevos nodos pueden sincronizarse en menos de medio día.
• Los nodos de archivo seguirán almacenando el historial completo; la disponibilidad de consultas antiguas dependerá de mecanismos como Portal Network y otras soluciones entre pares.

---

Ethereum reduce el peso de sus nodos y acelera la sincronización

EIP-4444 permite podar entre 300 y 500 GB de datos históricos. Nuevos nodos podrían sincronizarse en menos de medio día.

Los nodos de archivo conservarán el historial completo. El acceso a registros antiguos… pic.twitter.com/pXKHvc6TU9

— Diario฿itcoin (@DiarioBitcoin) September 26, 2026

Ethereum reduce el peso histórico de sus nodos y acelera la sincronización

La sincronización de un nodo de Ethereum puede completarse en menos de medio día con las optimizaciones asociadas a EIP-4444, que permiten dejar de conservar localmente parte de los datos históricos. Crypto Briefing informó que el cambio reduce los requisitos de almacenamiento entre 300 y 500 GB y facilita que un operador ponga en marcha un nodo funcional sin descargar y verificar una década de registros.

La modificación aborda una barrera práctica para quienes quieren participar en la red: el crecimiento continuo del espacio necesario para guardar datos. Sin embargo, no supone que Ethereum vaya a borrar su historia ni que todos los servicios puedan prescindir de ella; cambia qué información debe retener cada tipo de nodo y cómo se espera recuperar los registros antiguos cuando alguien los necesite.

Qué modifica EIP-4444 en la sincronización

La propuesta introduce una expiración parcial del historial: en lugar de exigir que cada nodo conserve todos los datos desde el inicio de la cadena, permite descartar registros antiguos una vez transcurrido un período definido. Según el artículo fuente, la activación ocurrió el 8 de julio de 2025 y afecta a los clientes de ejecución de Ethereum, que pueden podar datos anteriores a la Fusión, conocida como Merge.

El período de retención también cambió durante el diseño de la medida. La especificación inicial contemplaba cerca de 33.000 épocas, pero luego se revisó a alrededor de 82.000, un intervalo que la fuente describe como aproximadamente un año de historial; por tanto, el ajuste no equivale a eliminar todos los datos anteriores ni a detener la conservación de registros recientes.

La sincronización utiliza, además, referencias de seguridad conocidas como puntos de control de subjetividad débil para validar la cabecera actual de la cadena. En la capa de consenso, los operadores pueden recurrir a la sincronización por puntos de control, mientras que la capa de ejecución evita descargar y comprobar una larga secuencia de recibos de transacciones antiguos, una parte importante del trabajo asociado al historial acumulado.

La fuente señala que los cinco principales clientes de ejecución ya incorporaron soporte para las opciones y configuraciones necesarias. La lista incluye Geth v1.16.0, Nethermind 1.32.2, Besu 25.7.0, Erigon v3.0.12 y Reth v1.5.0, versiones que ofrecen a los operadores alternativas para aplicar la poda, aunque la disponibilidad de la función no significa que todos los nodos deban configurarse de manera idéntica.

Menos datos locales y requisitos de almacenamiento

Antes de este cambio, un nodo completo necesitaba más de 400 GB de almacenamiento y esa demanda aumentaba con cada bloque, interacción con contratos inteligentes y transferencia de tokens. Crypto Briefing cifra entre 300 y 500 GB la reducción derivada de la poda de información histórica anterior a la Fusión, un alivio que puede disminuir el espacio dedicado a registros que muchos operadores no consultan de forma habitual.

La noticia distingue entre un nodo completo y uno de archivo, una diferencia importante para entender el alcance de la medida. Los nodos completos y los validadores pueden aplicar la retención parcial descrita, mientras que los nodos de archivo, utilizados para servir consultas históricas a exploradores de bloques y plataformas de análisis, seguirán guardando todos los datos.

En cuanto al equipo, el artículo indica que un nodo plenamente funcional puede ejecutarse en un disco de 2 TB y que, con ajustes agresivos, el almacenamiento total puede mantenerse por debajo de 0,5 TB. Son cifras que describen configuraciones y resultados distintos: la primera plantea un disco de capacidad suficiente para operar, mientras la segunda corresponde a una reducción más intensa del espacio utilizado.

El resultado más visible para un nuevo operador sería un proceso de sincronización inferior a medio día, en contraste con sincronizaciones de varios días y necesidades de almacenamiento superiores a un terabyte que, según la fuente, podían encontrarse anteriormente. Una computadora de consumo con una unidad SSD adecuada podría participar con requisitos más modestos, aunque la experiencia concreta dependerá de la configuración elegida y de qué datos se decida conservar.

La historia no desaparece, pero deja de estar en todos los nodos

La poda cambia la distribución de los registros, no la existencia de la historia de Ethereum. Mientras los nodos completos retienen una parte acotada de los datos, los operadores de nodos de archivo mantienen el conjunto completo para atender solicitudes que requieren consultar información antigua, como ocurre con determinados servicios de exploración y análisis.

Esta separación permite que distintos participantes cumplan funciones diferentes en la red. Un nodo orientado a validar y seguir la cadena actual no tiene que cargar necesariamente con las mismas exigencias de almacenamiento que un servicio dedicado a responder consultas históricas, aunque esa especialización implica que la información antigua ya no estará replicada de manera uniforme en cada equipo.

El artículo vincula EIP-4444 con la fase Purge de la hoja de ruta de Ethereum, descrita por Vitalik Buterin como una etapa enfocada en reducir la complejidad del protocolo y los requisitos para los nodos. La poda encaja en ese objetivo al limitar la cantidad de historia que cada participante debe mantener, sin convertir esa reducción en una promesa de que cualquier dato pasado estará disponible de forma inmediata desde cualquier nodo.

Para cubrir parte de esa necesidad, la fuente menciona Portal Network y otras soluciones de disponibilidad de datos entre pares, diseñadas para que las consultas históricas puedan resolverse incluso cuando la mayoría de los nodos haya avanzado y podado registros. La utilidad de esos mecanismos resulta central en la transición, porque el acceso a datos antiguos dependerá cada vez más de dónde se almacenen y de cómo puedan encontrarse.

Un cambio de accesibilidad con una transición por resolver

La principal consecuencia operativa es que almacenar menos historia puede reducir el espacio y el tiempo iniciales necesarios para poner un nodo en funcionamiento. Esto podría ampliar el grupo de personas capaces de participar con equipos de consumo, pero no elimina la necesidad de servidores o nodos especializados cuando una aplicación requiere consultar información histórica completa.

La transición plantea un desafío de coordinación porque los nodos pueden podar a ritmos distintos, de acuerdo con sus configuraciones y períodos de retención. En ese escenario, la historia dejaría de estar copiada íntegramente en todos los participantes y pasaría a encontrarse distribuida entre distintos operadores y herramientas, de modo que la recuperación de ciertos registros dependería de mecanismos de disponibilidad y consulta.

Por eso, las cifras de sincronización y almacenamiento deben leerse junto con la distinción entre los tipos de nodo. Una reducción de cientos de gigabytes puede facilitar la operación cotidiana de un nodo completo, pero no reemplaza la capacidad de archivo que necesitan los exploradores de bloques y las plataformas de análisis para servir información antigua.

EIP-4444 propone, en suma, que participar en Ethereum no requiera que cada operador conserve todo el pasado de la red en su propio disco. La promesa de una sincronización inferior a medio día y de un uso de almacenamiento inferior a 0,5 TB en configuraciones agresivas convive con una pregunta aún abierta: cómo garantizar que la historia podada siga disponible y sea localizable cuando vuelva a hacer falta.

---

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.