← Volver a la Bitácora

La paradoja del CID en IPFS

Tarde o temprano, cualquiera que construya sobre IPFS se topa con la misma pared: querés que un archivo se refiera a sí mismo. Que el documento lleve adentro su propia dirección, que el manifiesto de una obra incluya el CID bajo el cual va a vivir. Parece un detalle de implementación. Es, en realidad, una imposibilidad criptográfica.

El problema circular

Un CID no es una URL asignada por alguien. Es un hash criptográfico derivado del contenido exacto del archivo: cambiás un solo byte y cambia por completo. De ahí nace el círculo:

  1. Tenés tu archivo original.
  2. Lo pasás por el algoritmo y generás el CID A.
  3. Tomás ese CID A y lo pegás dentro del archivo.
  4. El contenido cambió — ahora el archivo genera el CID B, y A quedó obsoleto.

Meter el hash dentro del archivo muta el archivo, y al mutarlo destruye el hash que acabás de meter. No hay forma de escapar por fuerza bruta: encontrar un contenido que se auto-referencie equivale a encontrar un punto fijo de SHA-256, que es exactamente lo que una función de hash criptográfica está diseñada para hacer imposible.

La salida: separar la dirección del contenido

La regla práctica es corta: nunca intentes meter un CID en el archivo que lo genera. En su lugar, usás un puntero mutable — un nombre o una llave que vos controlás, y que sí podés escribir adentro del archivo — apuntando al contenido inmutable.

El informe desarrolla las tres arquitecturas que implementan esa separación:

  • IPNS — un puntero nativo de IPFS, firmado con tu clave. Gratis, legible por máquinas, ideal para dApps dinámicas sin infraestructura propia.
  • DNSLink o ENS — el mismo principio con nombres legibles por humanos: escribís miarchivo.eth dentro del archivo y actualizás el registro para que apunte al CID recién generado. Requiere pagar un dominio, pero es lo indicado para documentos públicos orientados a personas.
  • Estructura de dos archivos — el contenido inmutable por un lado y un archivo de referencia que lo apunta por el otro. Gratis y nativo, para archivos puramente inmutables.

Cómo elegir

Ninguna de las tres es superior en abstracto; se eligen por quién va a consumir el archivo. Si lo lee una máquina dentro de una dApp, IPNS. Si lo lee una persona que escribe una dirección en el navegador, DNSLink o ENS. Si el archivo nunca va a cambiar, la estructura de dos archivos alcanza y sobra.

La criptografía no se engaña: la arquitectura se diseña a su alrededor.

El informe completo, con los diagramas del ciclo de mutación y la matriz de decisión comparada, está en el PDF.