Almacenamiento multi-nube sin lock-in — Arweave, IPFS, Hedera

La permanencia en Arweave es el piso, no un ítem de menú La función multi-backend de Evercore se malinterpreta a menudo como «elige una cadena». El modelo correcto es permanencia Arweave primero con capas de aumento gobernadas: 1. Permanencia — Arweave siempre forma parte del despliegue (primario o réplica obligatoria). 2. Escritura primaria — qué backend recibe primero los bytes cifrados (arweave o ipfs-kubo). 3. Réplica — espejos fire-and-forget con etiquetas (Evercore-Replicated-From, Evercore-Replicates). 4. Anclaje — mensajes de auditoría Hedera HCS opcionales vía workers Pub/Sub. POST /files/upload sigue siendo la puerta de entrada. Lo que cambia es cómo la ContentPolicy del inquilino dirige las capas 2–4 tras validación, cifrado y control de plan. Este artículo recorre los tres escenarios canónicos de MULTI_BACKEND_FLOW.md para que arquitectos los mapeen a latencia, costo y auditoría. Escenario A — Arweave puro (predeterminado) Cuándo elegir A: Quiere las garantías originales de Evercore sin operar kubo ni HCS. Muchos inquilinos en crecimiento permanecen aquí indefinidamente. Escenario B — Arweave primario + anclaje Hedera (auditoría dual) Cuándo elegir B: Cumplimiento quiere prueba de existencia en un log de consenso independiente además de Arweave—común en SOC 2, responsabilidad GDPR o programas que ya usan exploradores tipo HashScan. Costo dominado por tarifas HCS (~0,0001 USD por mensaje en mainnet; testnet gratis). Finalidad en segundos. Operadores inspeccionan con POST /hedera/audit/timeline, POST /hedera/audit/source y POST /hedera/anchor/verify. Console muestra hojas estructuradas, no JSON partido carácter a carácter. Escenario C — IPFS caliente primario + réplica Arweave + anclaje Hedera Cuándo elegir C: Lecturas diarias deben ir a IPFS caliente (milisegundos en su VPC), Arweave guarda el registro de largo plazo y Hedera la línea de auditoría consultable sin entender gateways CID. El script e2e:multi-backend-arweave-first valida este patrón: CID de carga, tx réplica bajo contentBackend=arweave, secuencia de anclaje, y POST /proofs/multi-anchor/verify con tarjetas paralelas en Console. ContentPolicy como plano de control Inquilinos configuran con GET/PUT/DELETE /storage/policy. Ámbitos incluyen storage:policy:read|write, storage:hedera:anchor, storage:ipfs:write|read|unpin y audit:timeline:read. La UI de política de almacenamiento muestra cuatro capas y fuerza permanencia Arweave si se elige IPFS primario—quitar la réplica Arweave muestra banner destructivo porque «caliente sin frío» rompe la narrativa de custodia. Los planes (packages/shared/src/plans.ts) limitan capacidades: Growth sin Hedera ni IPFS; Professional habilita ambos con topes; Enterprise añade temas por inquilino. El copy de /pricing enmarca la economía; este artículo cubre mecánica. Lectura, listado y reconciliación /files/list añade filtros contentBackend y anchored. Las filas exponen backendId y anchors[] para enlaces correctos (ViewBlock, gateway IPFS, HashScan). Los errores «Transaction ID must be 43 characters» para CIDs desaparecieron: un mismo menú actualiza estado de cadena para ambas familias. Verificación multi-anclaje como prueba de integración POST /proofs/multi-anchor/verify ejecuta comprobaciones Arweave, IPFS y Hedera en paralelo. Trate este endpoint como puerta de release al habilitar C: si alguna pierna falla tras las ventanas de espera configuradas, aún no tiene un camino empresarial defendible. Modos de fallo para runbooks • Retraso de réplica — Arweave es fire-and-forget; no asuma registro dual instantáneo. • Degradación de anclaje — Sin credenciales Hedera, el anclaje se omite en silencio; /health informa estado. • Denegaciones de plan — anchor: "hedera" en Growth falla en plan-gate.ts. • Confusión de localizador — Sistemas posteriores deben almacenar CID y tx réplica cuando C está activo. Dónde continuar • /platform/multi-backend y /platform/multi-backend/routing • apps/evercore-ms/docs/MULTI_BACKEND_FLOW.md • FAQ multi-backend en /pricing • E2E: npm run e2e:multi-backend-arweave-first desde evercore-ms Cierre Multi-backend no es «más cadenas para diapositivas». Es una tubería de escritura en capas donde Arweave sigue siendo el ancla de permanencia, IPFS opcionaliza lectura caliente y Hedera opcionaliza una línea de auditoría independiente—por política de inquilino, por plan y verificable con pruebas multi-anclaje. Elija A, B o C según latencia de lectura, independencia de auditoría y complejidad operativa—no según qué logo luce mejor.

Topics

• API almacenamiento multi-backend
• almacenamiento enterprise Arweave
• recuperación caliente IPFS GDPR
• anclaje auditoría Hedera
• enrutamiento ContentPolicy
• almacenamiento sin lock-in
• permanencia más lectura caliente
• verificación multi-ancla