La implementación de EIP-4444 permite que los nodos de Ethereum descarten datos históricos anteriores a la Fusión, reduciendo requisitos de almacenamiento entre 300 y 500 GB y acelerando la sincronización a menos de medio día.
¿Cómo funciona la poda de datos históricos en Ethereum?
EIP-4444 introduce un mecanismo de expiración parcial del historial que permite a los clientes de ejecución de Ethereum descartar información anterior a la Fusión (Merge) sin eliminar la historia completa de la red. En lugar de exigir que cada nodo conserve todos los datos desde el origen de la cadena, la propuesta establece un período de retención definido tras el cual los registros pueden ser podados localmente.
La activación de esta medida ocurrió el 8 de julio de 2025, marcando un punto de inflexión en la arquitectura de almacenamiento de la red. El período de retención se fijó en aproximadamente 82.000 épocas, equivalente a alrededor de un año de historial, lo que permite que los operadores mantengan datos recientes sin cargar con décadas de registros acumulados.
Reducción de requisitos de almacenamiento y sincronización más rápida
Antes de este cambio, un nodo completo requería más de 400 GB de almacenamiento, cifra que aumentaba constantemente con cada bloque, interacción de contrato inteligente y transferencia de tokens. La poda de datos históricos reduce esa demanda entre 300 y 500 GB, permitiendo que nuevos operadores sincronicen un nodo funcional en menos de medio día, en contraste con los procesos de varios días que eran comunes previamente.
Los cinco principales clientes de ejecución ya incorporaron soporte para estas optimizaciones:
- Geth v1.16.0
- Nethermind 1.32.2
- Besu 25.7.0
- Erigon v3.0.12
- Reth v1.5.0
Con configuraciones estándar, un nodo completo puede ejecutarse en un disco de 2 TB, mientras que con ajustes agresivos de almacenamiento el espacio total puede mantenerse por debajo de 0,5 TB. Esta reducción abre la posibilidad de que computadoras de consumo con unidades SSD adecuadas participen en la red con requisitos más modestos.
Nodos de archivo y distribución del historial
Es fundamental entender que EIP-4444 no elimina el historial de Ethereum ni lo borra de la red: modifica cómo se distribuye entre los diferentes tipos de nodo. Los nodos completos y validadores pueden aplicar la retención parcial descrita, reduciendo su almacenamiento local, mientras que los nodos de archivo continúan guardando todos los datos para servir consultas históricas a exploradores de bloques y plataformas de análisis.
Esta especialización de funciones permite que distintos participantes cumplan roles específicos en la red. Un nodo orientado a validar y seguir la cadena actual no necesita cargar con las mismas exigencias de almacenamiento que un servicio dedicado a responder consultas históricas, aunque implica que la información antigua dejaría de estar replicada uniformemente en cada equipo.
Portal Network y recuperación de datos históricos
La transición plantea un desafío operativo: garantizar que los datos podados sigan siendo accesibles cuando se necesiten. Para resolver esto, EIP-4444 se vincula con 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 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 checkpoint, mientras que en la capa de ejecución se evita descargar y verificar largas secuencias de recibos de transacciones antiguas, reduciendo significativamente el trabajo asociado al historial acumulado.
Impacto para empresas y administradores de infraestructura blockchain
Para operadores de nodos, desarrolladores de aplicaciones descentralizadas y proveedores de infraestructura blockchain en Argentina y la región, EIP-4444 representa una oportunidad de reducción de costos operativos y barrera de entrada más accesible. La disminución de requisitos de almacenamiento y la sincronización más rápida permiten que pequeñas y medianas empresas participen en la red con inversiones de hardware más modestas.
Sin embargo, quienes operen servicios que requieran consultas históricas completas —como exploradores de bloques, plataformas de análisis o sistemas de auditoría— deberán mantener nodos de archivo con capacidad de almacenamiento superior. La evaluación de infraestructura debe considerar no solo si se participa en validación, sino qué tipo de datos históricos cada aplicación necesita mantener accesible.
Esta medida se alinea 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 participantes. La poda de datos históricos cumple ese objetivo al limitar la cantidad de historia que cada nodo debe mantener, democratizando el acceso a la infraestructura de la red sin comprometer la integridad de sus registros.
