MemChain e armazenamento criptografado

“MemChain e armazenamento criptografado” é uma página localizada oficial da documentação AeroNyx. AeroNyx separa a camada de protocolo da experiência de produto: o protocolo fornece capacidades abertas e resilientes, enquanto App, Nodeboard, chat criptografado, armazenamento criptografado e operação de nós compõem a experiência do usuário.

Visão geral

Esta página explica em português do Brasil o papel de “MemChain e armazenamento criptografado” no protocolo aberto de privacidade AeroNyx, o escopo atual, os invariantes de privacidade e os cuidados de desenvolvimento e operação.

Papel na arquitetura AeroNyx

Este tema pertence a Nodeboard. O ponto central é entender AeroNyx não como um único serviço centralizado, mas como um conjunto de capacidades de protocolo compartilhadas por clientes, nós descentralizados de privacidade, coordenadores backend e Nodeboard.

Pontos atuais de implementação

Toda capacidade relacionada a conteúdo do usuário deve trafegar como criptografia ponta a ponta ou objeto criptografado.
Nós Rust podem reportar saúde, capacidade, conexões, provas de rota e estatísticas agregadas, mas não podem ler mensagens, credenciais ou segredos do usuário.
Nodeboard oferece observabilidade operacional: saúde do nó, peer discovery, recuperação após reinício, capacidade, pacotes/tráfego e estado do protocolo.
Na fase atual o backend coordena, ordena, agrega e expõe APIs públicas de documentação; algumas responsabilidades podem migrar depois para a camada Rust.

Limite de privacidade

O invariante central da AeroNyx é o blind-node invariant: nós de relay e coordenadores MemChain lidam apenas com ciphertext, timestamps, provas, sinais agregados de saúde e metadados limitados de roteamento. Eles não devem ler texto claro, DNS, destinos ou reconstruir relações sociais.

O que operadores devem acompanhar

Operadores devem acompanhar largura de banda, limites de conexão, pool de IP, conntrack, descritores de arquivo, packet drops, pps, bps, peer store, frescor de heartbeat e restart recovery. A interface deve ajudar no diagnóstico sem expor conteúdo de usuário ou dados vinculáveis.

Integração para desenvolvedores e produtos

Clientes, App, AI agents e serviços externos devem reutilizar envelopes criptografados, assinaturas, blind relay, credenciais anônimas e healthchecks da AeroNyx. Toda nova API deve separar metadados públicos de campos que permanecem dentro do E2E payload.

Estado atual

Esta página descreve a fronteira pública atual do protocolo e produto AeroNyx. multi-hop routing, blind-signed vouchers, encrypted media blob, sincronização MemChain e melhorias de node discovery devem continuar sob o mesmo translation_key.

Registro de compromissos e proteção contra rollback

O MemChain mantém um registro append-only de compromissos para dados criptografados. Um bloco contém compromissos de integridade e metadados de ordenação, não memórias em texto aberto nem chaves de descriptografia. Ele detecta adulteração e rollback; não é uma blockchain pública e não promete consenso distribuído, finalidade ou execução de tokens.

Antes de abrir UDP, TUN ou a API pública, o coordenador verifica, em ordem, o modo de durabilidade, toda a cadeia persistida, a âncora local assinada da ponta, as evidências de checkpoint armazenadas e os checkpoints assinados dos nós externos fixados pelo operador.

Resultado verificado	Decisão de inicialização
Convergente	Continuar
Remoto atrasado	Continuar
Remoto adiantado	Parar: possível rollback local
Histórico divergente	Parar: os históricos assinados entram em conflito
Sem evidência assinada	Continuar degradado apenas sem strict; com strict, parar

As testemunhas devem ser identidades Ed25519 fixadas explicitamente pelo operador. Um peer permissionless não ganha autoridade de inicialização apenas por aparecer no peer store.

Implantação de produção verificada — 14 de julho de 2026

Um coordenador de produção tem três identidades witness fixadas pelo operador. Dois followers operados de forma independente e auditados agora oferecem checkpoints compatíveis; cada um verificou e armazenou o mesmo histórico de 33 blocos e 8.339 compromissos. O coordenador aceitou respostas converged distintas e assinadas pelos dois followers e, em seguida, ativou commitment_witness_startup_required = true.

Na reinicialização verificada, o startup guard registrou configured=3, eligible=3, attempted=3, verified=2 e converged=2; os listeners UDP e TUN só foram abertos após a aprovação da verificação. Isso é evidência de rollback fixada pelo operador, não consenso, quorum, finalidade de cadeia pública ou execução de tokens.

O heartbeat informa apenas o escopo, a quantidade e a exigência strict das testemunhas; não envia identidades, endpoints, hashes, assinaturas, conteúdo criptografado, proprietários ou relações sociais.

Limite de inicialização 2-of-3 aplicado — 14 de julho de 2026

O coordenador de produção agora define commitment_witness_min_verified = 2 junto com commitment_witness_startup_required = true. A inicialização é interrompida quando menos de dois witnesses fixados e distintos fornecem evidência assinada válida: zero respostas válidas geram signed_checkpoint_unavailable e uma gera signed_checkpoint_threshold_unmet. O último reinício de produção verificou dois dos três witnesses configurados antes de abrir UDP, TUN ou o listener da API pública.

Esse é um limite de inicialização definido pelo operador, não consensus de rede, quorum, finality, eleição de líder ou fork choice. O heartbeat Rust informa apenas campos agregados de política e resultado, incluindo startup_minimum_verified, sem expor identidades, endpoints, hashes de checkpoint ou assinaturas.

Especificação relacionada

Ledger assinado de compromissos e proteção por testemunhas

Cérebro próprio e limite do provedor de modelos

O MemChain separa armazenamento cego para o nó de processamento cognitivo opcional. Ativar um cognitive worker SuperNode não dá aos nós de armazenamento ou relay permissão para ler a memória.

O que cada componente pode ver

Um nó de armazenamento ou relay node-blind vê ciphertext, blind indexes, metadados limitados de rota e sinais agregados de saúde; por padrão não recebe memória em texto claro.
Um cognitive worker SuperNode habilitado recebe somente o payload permitido pelo nível structured, summary ou full.
Um provedor externo de modelos pode ler o prompt exato enviado a ele. Use full apenas com consentimento explícito e um provedor escolhido como confiável.
Um modelo local compatível com OpenAI mantém a inferência dentro do limite do operador, mas seu worker continua sendo um processador confiável, não um nó de armazenamento cego.

Isolamento em runtime

Respostas bem-sucedidas são limitadas a 8 MiB antes do parse JSON; corpos de diagnóstico de erro são limitados a 64 KiB.
Falhas de transporte, API, parse ou resposta vazia colocam o provedor em cooldown monotônico de 30 segundos, em vez de desativá-lo para sempre.
HTTP 429 Retry-After é respeitado entre 1 e 300 segundos; sem valor, são usados 30 segundos.
O router pode usar outro provedor saudável e reconsidera automaticamente o provedor com falha após o cooldown. Não é necessária tarefa agendada.

Esses limites protegem a disponibilidade do nó, mas não tornam a inferência externa E2E. O provedor externo continua sendo uma decisão de confiança separada e explícita.