Operação de nós descentralizados de privacidade

“Operação e health checks de nós descentralizados de privacidade” é 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 “Operação e health checks de nós descentralizados de privacidade” 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 Operadores de nós. 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.

Especificação relacionada

Ledger assinado de compromissos e proteção por testemunhas

Verificação de integridade do MemChain AOF

Inclua esta barreira somente leitura em todo upgrade e restart planejado. A saída agregada é segura para automação operacional.

bash

sudo aeronyx-server memchain verify-aof \
  --config <node-config>

sudo aeronyx-server memchain verify-aof \
  --path <node-state>

Resultado	Ação do operador
`status: verified` e `torn_tail_bytes: 0`	Prossiga com validação da configuração e guarded restart.
`torn_tail_detected`	Não edite o arquivo. Apenas guarded append-open pode remover a cauda física incompleta após scan semântico completo.
Erro de integridade	Pare. Preserve AOF e logs; corrupção semântica de registro completo falha de forma fechada.

Privacidade: Nunca envie, cole ou publique o AOF. Compartilhe apenas a saída agregada do verifier.

Limite completo de integridade e prova: Ledger assinado de compromissos e proteção por testemunhas.

Manutenção controlada do cache de compilação Cargo

Compilações repetidas podem deixar dezenas de GB de objetos Cargo regeneráveis. O comando unificado inspeciona e recupera espaço sem apagar estado do protocolo nem reiniciar o serviço.

1. Inspeção sem alterar o host

Execute primeiro o inventário somente leitura. Ele mostra o target legado, build root isolado, versão Rust fixada, SHA-256 do binário protegido e capacidade agregada do sistema de arquivos.

bash

cd <node-repository>
./deploy/node/aeronyx-node.sh build-cache --repo-dir "$PWD"

2. Prévia de cada item removível

Revise o dry-run linha por linha. A exclusão exige root e --yes explícito; status e upgrade nunca iniciam limpeza implícita.

bash

sudo ./deploy/node/aeronyx-node.sh prune-build-cache \
  --repo-dir "$PWD" \
  --dry-run

3. Execução da limpeza confirmada

bash

sudo ./deploy/node/aeronyx-node.sh prune-build-cache \
  --repo-dir "$PWD" \
  --yes

Se usar um build root personalizado, exporte AERONYX_BUILD_TARGET_ROOT nos três comandos para que inventário e limpeza usem o mesmo target isolado.

Escopo protegido e removível

Protegido: Preserva target/release/aeronyx-server, cache atual de toolchain/serviço, outros executáveis release e artefatos rollback, dados do protocolo em <node-state>, identidade/configuração em <node-config-directory> e caches de outros serviços.
Regenerável: Remove apenas saídas Cargo regeneráveis: diretórios debug/cross-target antigos, deps, build, .fingerprint, incremental, .rlib, .rmeta, .d e targets de toolchains antigos do mesmo serviço.
Proteção de execução: Antes de excluir, obtém o deployment lock compartilhado com install/upgrade e confirma que o MainPID executa o binário protegido. Calcula o hash antes e depois e falha se houver mudança.

Verificação pós-manutenção

A limpeza não reinicia o nó nem exige drenar sessões ativas. Depois confirme service health, startup readiness, discovery quorum e atualidade da prova de dois saltos.

bash

./deploy/node/aeronyx-node.sh status --repo-dir "$PWD"
./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json

Evidência de validação em produção — 26 de julho de 2026

Uma execução controlada recuperou 50,649,768 KiB; o uso caiu de 90% para 65%. SHA-256, MainPID e reinícios não mudaram; startup seguiu sem falhas e a prova de dois saltos ficou ready/stable.

Limite de privacidade: O inventário mostra apenas paths locais, tamanhos, versão do toolchain, hash do binário e capacidade agregada. Não lê payloads cifrados, registros MemChain, chaves, identidades peer, rotas, endereços cliente, DNS, destinos ou grafo social.

Operação do cognitive worker opcional

O cognitive worker SuperNode é opcional e desativado por padrão. Ative apenas em um nó de processamento cujo papel de confiança esteja claro.

Configuração mínima de provedor local

toml

[memchain.supernode]
enabled = true

[[memchain.supernode.providers]]
name = "local-ollama"
type = "openai_compatible"
api_base = "http://localhost:11434/v1"
api_key = ""
model = "llama3.2"
max_tokens = 1000
temperature = 0.3

[memchain.supernode.routing]
fallback = "local-ollama"

[memchain.supernode.privacy]
default_level = "structured"
allow_full_for = []

api_key = "$ENV_VAR" também é aceito. Não coloque segredos em configuração versionada.

Formas de endpoint compatíveis com OpenAI

As três formas resolvem para o mesmo endpoint Chat Completions:

https://provider.example
https://provider.example/v1
https://provider.example/v1/chat/completions

Para type = "anthropic", api_base pode ser omitido; o runtime atual usa o endpoint oficial Anthropic Messages.

Falhas e limites de recursos

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.

Antes de reiniciar, execute aeronyx-server validate -c <node-config>. O comportamento está no main atual; um nó instalado precisa ser recompilado ou atualizado para uma versão que o contenha.

Limite de privacidade: nós de armazenamento e relay continuam node-blind. O cognitive worker habilitado e qualquer provedor externo veem o prompt permitido pelo nível de privacidade. Mantenha default_level = "structured" e allow_full_for vazio sem consentimento explícito para conteúdo completo.