La reducción de Gas gracias a la actualización de CUN en realidad es genial, pero hay un detalle fácil de pasar por alto: los datos Blob de EIP-4844 solo se conservan en los nodos durante 18 días y luego se eliminan automáticamente. Esto puede parecer una tontería, pero en realidad es bastante problemático: después de unos años, puede ser imposible recuperar el historial de una transacción Layer2 específica.

Desde un punto de vista técnico, Ethereum tiene sus razones para hacerlo: aliviar la carga de los nodos y reducir la presión de almacenamiento. Pero, ¿a qué costo? El historial completo del libro mayor de Layer2 se ve pasivamente debilitado. Decir que se trata de una «contabilidad descentralizada» y no poder consultar datos de hace tres años, en realidad, resulta un poco incómodo.

La lógica aquí es bastante clara: la cadena principal no puede manejar todos los datos históricos, por lo que alguien debe hacerse cargo. Una idea viable es usar mecanismos de cross-chain sin confianza para transferir automáticamente los Blob que están por expirar a una capa de almacenamiento de datos especializada, formando una arquitectura en capas de «datos calientes en Ethereum, datos fríos almacenados en ubicaciones remotas». De esta forma, Layer2 puede beneficiarse de la seguridad de la cadena principal sin que la pérdida de datos debilite la verificabilidad.

Al final, Layer2 que se promociona como «seguro y descentralizado» debe tener una base sólida en la trazabilidad del historial completo. El diseño del almacenamiento de datos está directamente relacionado con la confianza en todo el ecosistema.