Armazenamento multi-nuvem sem lock-in — Arweave, IPFS, Hedera

Permanência Arweave é o piso, não item de cardápio O recurso multi-backend do Evercore é mal interpretado como «escolha uma chain». O modelo correto é permanência Arweave primeiro com camadas de augmentação governadas: 1. Permanência — Arweave sempre faz parte do deployment (primário ou réplica obrigatória). 2. Escrita primária — qual backend recebe primeiro os bytes cifrados (arweave ou ipfs-kubo). 3. Réplica — espelhos fire-and-forget com tags (Evercore-Replicated-From, Evercore-Replicates). 4. Âncora — mensagens de auditoria Hedera HCS opcionais via workers Pub/Sub. POST /files/upload continua sendo a porta de entrada. O que muda é como a ContentPolicy do tenant direciona as camadas 2–4 após validação, cifragem e gate de plano. Este artigo percorre os três cenários canônicos de MULTI_BACKEND_FLOW.md para arquitetos mapearem latência, custo e auditoria. Cenário A — Arweave puro (padrão) Quando escolher A: Quer garantias originais do Evercore sem operar kubo ou HCS. Cenário B — Arweave primário + âncora Hedera (auditoria dual) Quando escolher B: Conformidade quer prova de existência em log de consenso independente além de Arweave. Custo dominado por taxas HCS (~US$ 0,0001 por mensagem no mainnet; testnet grátis). Finalidade em segundos. Operadores inspecionam com POST /hedera/audit/timeline, POST /hedera/audit/source e POST /hedera/anchor/verify. O Console mostra folhas estruturadas. Cenário C — IPFS quente primário + réplica Arweave + âncora Hedera Quando escolher C: Leituras do dia a dia em IPFS quente; Arweave guarda registro de longo prazo; Hedera a linha de auditoria. O script e2e:multi-backend-arweave-first valida: CID de upload, tx réplica, sequência de âncora e POST /proofs/multi-anchor/verify com cartões paralelos no Console. ContentPolicy como plano de controle Tenants configuram com GET/PUT/DELETE /storage/policy. Escopos incluem storage:policy:read|write, storage:hedera:anchor, storage:ipfs:write|read|unpin e audit:timeline:read. A UI de política mostra quatro camadas e força permanência Arweave com IPFS primário. Planos (packages/shared/src/plans.ts) limitam capacidades. Copy em /pricing enquadra economia; este artigo cobre mecânica. Leitura, listagem e reconciliação /files/list adiciona filtros contentBackend e anchored. Erros «Transaction ID must be 43 characters» para CIDs foram removidos. Verificação multi-âncora POST /proofs/multi-anchor/verify executa checagens Arweave, IPFS e Hedera em paralelo. Use como portão de release ao habilitar C. Modos de falha para runbooks • Atraso de réplica — não assuma registro dual instantâneo. • Degradação de âncora — sem credenciais Hedera, âncora é omitida; /health informa. • Negações de plano — anchor: "hedera" em Growth falha em plan-gate.ts. • Confusão de localizador — armazene CID e tx réplica quando C está ativo. Próximos passos • /platform/multi-backend e /platform/multi-backend/routing • apps/evercore-ms/docs/MULTI_BACKEND_FLOW.md • FAQ em /pricing • E2E: npm run e2e:multi-backend-arweave-first Correlação com trace e exportação Cenários B e C produzem linhas na timeline Hedera (/hedera/audit/timeline) que auditores podem correlacionar com chainId de trace e pacotes de exportação de conformidade. Ao desenhar runbooks, inclua os três identificadores — localizador primário, tx réplica (se C) e sequência HCS — no mesmo ticket de evidência. Fechamento Multi-backend é pipeline de escrita em camadas onde Arweave permanece âncora de permanência, IPFS opcionaliza leitura quente e Hedera opcionaliza linha de auditoria independente — por política, por plano e verificável com provas multi-âncora. Escolha A, B ou C por latência, independência de auditoria e complexidade operacional — não por qual logo fica melhor no slide. Valide com o script E2E e com multi-anchor/verify antes de prometer SLAs de auditoria a reguladores.

Topics

• API armazenamento multi-backend
• armazenamento enterprise Arweave
• recuperação quente IPFS GDPR
• âncora auditoria Hedera
• roteamento ContentPolicy
• armazenamento sem lock-in
• permanência mais leitura quente
• verificação multi-âncora