Hosting descentralizado: arquitectura, verificación y compensaciones operativas

Alcance y el modelo mental del hosting descentralizado

El hosting descentralizado es un modelo de entrega en el que los archivos de un sitio web se almacenan y sirven mediante una red de nodos independientes en lugar de un único servidor de origen. Los dos mecanismos que lo definen son el direccionamiento de contenido, donde un archivo se identifica mediante un hash criptográfico de sus bytes, y la recuperación entre pares, donde un cliente solicita a múltiples nodos los bloques detrás de ese hash. El hosting web descentralizado y el hosting de sitios web descentralizado suelen añadir una capa de nombres por encima, porque los humanos necesitan URL estables mientras que los hashes de contenido cambian cada vez que un archivo cambia.

La consecuencia práctica es que el hosting se convierte en dos problemas separados: persistencia (mantener al menos un nodo dispuesto a almacenar el contenido) y resolución (mapear un nombre legible por humanos al identificador de contenido actual). Un sitio puede ser perfectamente recuperable hoy y desaparecer mañana si ningún nodo lo está fijando, lo cual es la sorpresa operativa más común. Este artículo trata esos dos problemas por separado y ofrece pasos de verificación para cada uno.

• Capa de contenido: los archivos se dividen en bloques, se hashean y se direccionan mediante un identificador de contenido (CID).
• Capa de persistencia: los servicios de pinning o los nodos autooperados mantienen los bloques disponibles.
• Capa de resolución: los nombres mutables (DNSLink, registros en cadena o sistemas de nombres) apuntan al CID actual.
• Capa de recuperación: los gateways o los nodos locales obtienen bloques de los pares y reensamblan el archivo.

Supuestos y requisitos previos antes de migrar un sitio

Los procedimientos a continuación asumen que tiene una salida de compilación de un sitio estático (HTML, CSS, JavaScript, imágenes) y una máquina con curl, Node.js y Python 3 disponibles. También asumen que puede ejecutar un nodo local compatible con IPFS o conectarse a un servicio de pinning; los comandos usan marcadores de posición como RPC_URL y PINNING_API_URL en lugar de endpoints públicos inventados. Si su sitio depende de renderizado del lado del servidor, API autenticadas o una base de datos relacional, el hosting descentralizado cubre solo la capa de entrega estática y aún necesitará cómputo convencional detrás.

Antes de migrar, inventaríe cada activo por tipo y tamaño, anote qué archivos cambian en cada despliegue y decida si el sitio necesita un nombre mutable o puede tolerar un nuevo CID por versión. Los equipos que omiten este paso suelen descubrir que su compilación genera nombres de archivo con hash en cada despliegue, lo que invalida los supuestos de caché y hace que el direccionamiento inmutable sea menos útil de lo esperado.

• Un directorio de compilación estático que pueda hashear y subir.
• Una clave API de servicio de pinning o un nodo autoalojado con almacenamiento persistente.
• Una URL de gateway que controle o en la que confíe para la verificación.
• Una decisión de nombres: CID inmutable por versión, o un registro mutable actualizado en el despliegue.

La ruta de recuperación desde el identificador de contenido hasta el navegador

Cuando un navegador solicita contenido a través de un gateway, el gateway analiza el CID, verifica su almacén de bloques local y, si el bloque falta, consulta a los pares mediante una tabla hash distribuida y registros de proveedores directos. Luego, el gateway verifica cada bloque contra el hash incrustado en el CID antes de devolver los bytes al cliente. Esta verificación es la propiedad de seguridad que el hosting centralizado carece por defecto: un par malicioso no puede sustituir contenido diferente sin romper el hash.

La ruta tiene más saltos que una CDN, por lo que la latencia depende de la disponibilidad de los pares y del almacenamiento en caché del gateway. Un gateway que ya ha almacenado en caché el CID responde rápidamente; un CID frío puede tardar segundos mientras se descubren los pares. Para el hosting de sitios web descentralizado, esto significa que el primer visitante después de un despliegue a menudo paga el costo de descubrimiento, y los visitantes posteriores se benefician de las cachés del gateway. Medir tanto la recuperación en frío como en caliente es esencial antes de sacar conclusiones sobre el rendimiento.

Pinning y publicación de una compilación estática con comandos ejecutables

El pinning es el acto de indicar a un nodo que retenga contenido específico indefinidamente. El siguiente procedimiento de shell publica un directorio de compilación, captura el CID resultante y lo fija a través de la API de un servicio de pinning. Reemplace los marcadores de posición con sus propios valores; no pegue claves de producción en shells compartidos.

set -euo pipefail

BUILD_DIR="./dist"
PINNING_API_URL="https://your-pinning-service.example/api/v0"
PINNING_TOKEN="$PINNING_TOKEN"

# Add the directory recursively and capture the root CID
ADD_RESPONSE=$(curl -s -X POST "$PINNING_API_URL/add" \
  -H "Authorization: Bearer $PINNING_TOKEN" \
  -F "file=@${BUILD_DIR}" \
  -F "recursive=true")

ROOT_CID=$(printf '%s' "$ADD_RESPONSE" | python3 -c 'import sys,json; print(json.load(sys.stdin)["Hash"])')
echo "Published root CID: $ROOT_CID"

# Pin the root explicitly so it survives garbage collection
curl -s -X POST "$PINNING_API_URL/pin/add?arg=${ROOT_CID}" \
  -H "Authorization: Bearer $PINNING_TOKEN"

echo "$ROOT_CID" > .last-published-cid

Verificación de la consistencia del gateway y la integridad del contenido

Una única recuperación exitosa solo demuestra que un gateway tenía el contenido en ese momento. La verificación de integridad requiere obtener el mismo CID de al menos dos gateways independientes y comparar los bytes. El siguiente script recupera un archivo por CID de dos gateways, calcula SHA-256 de cada respuesta e informa si coinciden. También verifica el estado HTTP para que un gateway que devuelve una página de error no se confunda con una discrepancia de contenido.

import hashlib, os, sys, urllib.request

CID = os.environ.get("CID", "")
PATH = os.environ.get("PATH_IN_SITE", "index.html")
GATEWAYS = [
    os.environ.get("GATEWAY_A", ""),
    os.environ.get("GATEWAY_B", ""),
]

if not CID or not all(GATEWAYS):
    sys.exit("Set CID, GATEWAY_A, and GATEWAY_B")

def fetch(base):
    url = f"{base.rstrip('/')}/ipfs/{CID}/{PATH}"
    req = urllib.request.Request(url, headers={"User-Agent": "hosting-verify/1.0"})
    with urllib.request.urlopen(req, timeout=30) as resp:
        body = resp.read()
        return resp.status, hashlib.sha256(body).hexdigest(), len(body)

results = []
for gw in GATEWAYS:
    try:
        status, digest, size = fetch(gw)
        results.append((gw, status, digest, size))
        print(f"{gw} status={status} sha256={digest} bytes={size}")
    except Exception as exc:
        print(f"{gw} ERROR {exc}")

if len(results) == 2 and results[0][2] == results[1][2]:
    print("MATCH: gateways returned identical bytes")
else:
    print("MISMATCH or incomplete: investigate before trusting the deployment")

Procedimiento de tabla de resultados para una evaluación de hosting

Registre cada ejecución de verificación en una tabla para que el comportamiento en frío y en caliente sean distinguibles. No rellene números de memoria; ejecute el procedimiento y pegue observaciones reales. Una tabla de evaluación defendible tiene estas columnas y al menos cinco filas por par de gateways, tomadas en diferentes momentos del día.

La tabla solo es significativa si la columna CID es idéntica entre filas para la misma versión. Si su pipeline de despliegue produce un nuevo CID en cada compilación, etiquete cada versión por separado y compare dentro de una versión, no entre versiones.

Diagnóstico de contenido sin pinning y fallos de descubrimiento de pares

El incidente de hosting descentralizado más frecuente es contenido que se añadió pero nunca se fijó, por lo que deja de estar disponible después de que el nodo que lo añadió recolecte su almacén de bloques. El segundo más frecuente es un gateway que no puede encontrar pares para un CID porque el contenido solo se almacenó en un nodo detrás de NAT sin registros de proveedor. Ambos se presentan de forma idéntica al usuario: un tiempo de espera agotado o un 504 del gateway.

Diagnostique en este orden: confirme que el CID está fijado en al menos un nodo siempre activo, consulte el estado del pin en el servicio de pinning y luego intente la recuperación a través de un nodo local en lugar de un gateway. Si el nodo local recupera el contenido pero el gateway no, el problema es el almacenamiento en caché o el emparejamiento del lado del gateway, no la persistencia. Si ninguno lo recupera, el contenido está efectivamente perdido y debe volver a añadirse y fijarse.

• Verifique el estado del pin a través de la API de pinning antes de suponer una falla de red.
• Recupere a través de un nodo local para separar la persistencia del comportamiento del gateway.
• Confirme que el CID en la URL coincide con el CID que fijó; una diferencia de un solo carácter cambia el hash.
• Para nombres mutables, confirme que el registro de nombre apunta al CID previsto y no ha expirado.

Nombres mutables, almacenamiento en caché y semántica de despliegue

Los CID inmutables son excelentes para la integridad pero incómodos para sitios que cambian. Las capas de nombres mutables resuelven esto almacenando un puntero que se actualiza en cada despliegue. La compensación es que el puntero introduce un paso de resolución con su propia latencia de almacenamiento en caché y propagación, y los clientes pueden almacenar en caché el puntero antiguo durante más tiempo del esperado. Cuando actualice un registro de nombre, verifique la resolución desde un cliente nuevo y desde un cliente que previamente resolvió el valor antiguo.

El almacenamiento en caché también interactúa con el direccionamiento de contenido de una manera que sorprende a los equipos: como los CID son inmutables, los gateways pueden almacenarlos en caché de forma agresiva, lo cual es bueno para los visitantes recurrentes pero significa que una reversión a un CID anterior puede servir cachés obsoletas del gateway. Planifique los despliegues de modo que la reversión apunte a un CID conocido como bueno y verifíquelo mediante el mismo procedimiento de consistencia de gateways descrito anteriormente.

Limitaciones y compensaciones frente al hosting centralizado

El hosting descentralizado no es un reemplazo directo para todas las cargas de trabajo. La lógica dinámica del servidor, las sesiones autenticadas y las páginas respaldadas por bases de datos aún requieren cómputo convencional, y la capa descentralizada normalmente se sitúa delante como una capa de entrega estática. El rendimiento también es menos predecible que el de una CDN bien ajustada porque la recuperación depende de la disponibilidad de los pares y del almacenamiento en caché del gateway, por lo que las aplicaciones sensibles a la latencia deben medir el comportamiento en frío en lugar de asumir cifras de caché en caliente.

Operativamente, el modelo traslada la responsabilidad: debe monitorear el estado del pin, la resolución de nombres y la consistencia del gateway usted mismo, porque no hay un único panel de proveedor que cubra los tres. El beneficio es la resistencia a la censura y la verificación de integridad por construcción; el costo es que la persistencia es una política que usted aplica, no una propiedad que compra. Los equipos deben decidir explícitamente cuál de esas necesidades tienen antes de migrar.

• La persistencia es tan confiable como su política de pinning y su monitoreo.
• La latencia de recuperación en frío puede ser significativamente mayor que la recuperación en caliente.
• Los nombres mutables añaden latencia de propagación y complejidad de caché.
• La lógica del lado del servidor aún necesita infraestructura convencional.

Próximos pasos para una evaluación de hosting en producción

Comience con un único sitio estático y ejecute los procedimientos de pinning, consistencia de gateways y tabla de resultados durante una semana antes de comprometerse. Instrumente el estado del pin y la resolución de nombres como comprobaciones monitoreadas, no como pasos manuales únicos. Si su aplicación también depende de leer el estado de la cadena o servir respuestas de API, combine la capa de hosting estático con acceso RPC confiable; el servicio API de OnFinality y las opciones de nodos dedicados cubren el lado del cómputo, mientras que el directorio de redes le ayuda a confirmar qué cadenas necesita. Para la selección de endpoints específicamente, la guía del RPC Assistant sobre hosting de nodos blockchain y endpoints RPC multicadena complementa esta metodología de hosting sin reemplazarla.

Por último, documente su ruta de reversión: el último CID conocido como bueno, el procedimiento de actualización del registro de nombre y el comando de verificación que su ingeniero de guardia debe ejecutar. Un despliegue de hosting descentralizado solo está listo para producción cuando un nuevo ingeniero puede reproducir los pasos de verificación solo con ese documento.