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.

Operação de testemunhas fixadas

As testemunhas fixadas são uma política explícita de confiança do operador para o coordenador de compromissos do MemChain. Configure apenas followers independentes, auditados e destinados a preservar o histórico do coordenador.

toml

[memchain]
commitment_coordinator_enabled = true
commitment_witness_node_ids = ["<64-hex-ed25519-node-id-1>", "<64-hex-ed25519-node-id-2>"]
commitment_witness_startup_required = false
commitment_witness_min_verified = 2

Substitua todos os placeholders antes de validar. São aceitas no máximo três identidades Ed25519 únicas, não nulas e de 32 bytes; essas opções só são válidas no coordenador.

Rollout seguro: atualize pelo menos dois followers auditados; adicione os IDs exatos com strict desativado; execute aeronyx-server validate -c /etc/aeronyx/server.toml; reinicie e confirme evidência assinada com escopo operator_pinned; ative strict apenas após repetir o teste.

Sem strict, witness indisponível gera um aviso degraded visível, mas preserva a disponibilidade. Um remote-ahead ou divergence assinado sempre bloqueia a inicialização. Com strict, a ausência de evidência verificada também bloqueia.

Checkpoint é um endpoint de protocolo assinado; um GET anônimo não é health check. As testemunhas melhoram a detecção de rollback, mas não criam, por si só, consenso, quorum ou finalidade.

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.

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

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 /etc/aeronyx/server.toml

sudo aeronyx-server memchain verify-aof \
  --path /var/lib/aeronyx/.memchain

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 /root/open/AeroNyx
./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 /var/lib/aeronyx, identidade/configuração em /etc/aeronyx 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://127.0.0.1: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 /etc/aeronyx/server.toml. 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.