Operación de nodos descentralizados de privacidad

«Operación y health checks de nodos descentralizados de privacidad» es una página localizada oficial de la documentación de AeroNyx. AeroNyx separa la capa de protocolo de la experiencia de producto: el protocolo aporta capacidades abiertas y resistentes, mientras App, Nodeboard, chat cifrado, almacenamiento cifrado y operación de nodos forman la experiencia de uso.

Resumen

Esta página explica en español el papel de «Operación y health checks de nodos descentralizados de privacidad» dentro del protocolo abierto de privacidad AeroNyx, su alcance actual, sus invariantes de privacidad y las notas de desarrollo y operación.

Lugar dentro de la arquitectura AeroNyx

Este tema pertenece a Operadores de nodos. La idea clave es no ver AeroNyx como un único servicio centralizado, sino como un conjunto de capacidades de protocolo que pueden compartir clientes, nodos descentralizados de privacidad, coordinadores backend y Nodeboard.

Puntos clave de implementación

Toda capacidad relacionada con contenido de usuario debe viajar como cifrado extremo a extremo o como objeto cifrado.
Los nodos descentralizados de privacidad pueden reportar salud, capacidad, conexiones, pruebas de ruta y estadísticas agregadas, pero no leer mensajes, credenciales ni secretos del usuario.
Nodeboard ofrece observabilidad operativa: salud del nodo, peer discovery, recuperación tras reinicio, capacidad, paquetes/tráfico y estado del protocolo.
En la fase actual el backend coordina, ordena, agrega y expone APIs públicas de documentación; algunas responsabilidades pueden migrar después hacia la capa Rust.

Límite de privacidad

El invariante central de AeroNyx es blind-node invariant: los nodos de relay y los coordinadores de MemChain solo manejan ciphertext, marcas de tiempo, pruebas, señales agregadas de salud y metadatos de ruta limitados. No deben leer texto claro, DNS, destinos ni reconstruir relaciones sociales.

Qué deben vigilar los operadores

El operador debe observar ancho de banda, límites de conexión, pool de IP, conntrack, descriptores de archivo, packet drops, pps, bps, peer store, frescura de heartbeat y restart recovery. La interfaz debe ayudar a diagnosticar sin exponer contenido de usuario ni datos vinculables.

Integración para desarrolladores y productos

Clientes, App, AI agents y servicios externos deben reutilizar el envelope cifrado, firmas, blind relay, credenciales anónimas y healthchecks de AeroNyx. Toda API nueva debe separar metadatos públicos de campos que deben permanecer dentro del E2E payload.

Estado actual

Esta página describe el límite público actual del protocolo y producto AeroNyx. multi-hop routing, blind-signed vouchers, encrypted media blob, sincronización de MemChain y mejoras de node discovery deben mantenerse bajo el mismo translation_key.

Operación de testigos fijados

Los testigos fijados son una política explícita de confianza del operador para el coordinador de compromisos de MemChain. Configure solo followers independientes, auditados y destinados a conservar el historial del coordinador.

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

Sustituya todos los marcadores antes de validar. Se aceptan como máximo tres identidades Ed25519 únicas, no nulas y de 32 bytes; estas opciones solo son válidas en el coordinador.

Despliegue seguro: actualice al menos dos followers auditados; añada sus ID exactos con strict desactivado; ejecute aeronyx-server validate -c /etc/aeronyx/server.toml; reinicie y confirme evidencia firmada con alcance operator_pinned; active strict solo después de repetir la prueba.

Sin strict, la falta de conectividad genera una advertencia degraded visible pero mantiene la disponibilidad. Un remote-ahead o divergence firmado siempre bloquea el arranque. Con strict, no disponer de evidencia verificada también lo bloquea.

Checkpoint es un endpoint de protocolo firmado; un GET anónimo no es un health check. Los testigos mejoran la detección de rollback, pero no crean por sí solos consenso, quorum ni finalidad.

Despliegue de producción verificado — 14 de julio de 2026

Un coordinador de producción tiene tres identidades witness fijadas por el operador. Dos followers operados de forma independiente y auditados ya ofrecen checkpoints compatibles; cada uno verificó y almacenó el mismo historial de 33 bloques y 8.339 compromisos. El coordinador aceptó respuestas converged distintas y firmadas por ambos followers y después activó commitment_witness_startup_required = true.

En el reinicio verificado, el startup guard informó configured=3, eligible=3, attempted=3, verified=2 y converged=2; los listeners UDP y TUN solo se abrieron tras superar la comprobación. Es evidencia de rollback fijada por el operador, no consenso, quorum, finalidad de una cadena pública ni ejecución de tokens.

Umbral de arranque 2-of-3 aplicado — 14 de julio de 2026

El coordinador de producción ahora configura commitment_witness_min_verified = 2 junto con commitment_witness_startup_required = true. El arranque se detiene cuando menos de dos witnesses fijados y distintos aportan evidencia firmada válida: cero respuestas válidas generan signed_checkpoint_unavailable y una genera signed_checkpoint_threshold_unmet. El último reinicio de producción verificó dos de los tres witnesses configurados antes de abrir UDP, TUN o el listener de la API pública.

Es un umbral de arranque definido por el operador, no consenso de red, quorum, finalidad, elección de líder ni fork choice. El heartbeat de Rust solo informa campos agregados de política y resultado, incluido startup_minimum_verified, sin exponer identidades, endpoints, hashes de checkpoint ni firmas.

Especificación relacionada

Registro firmado de compromisos y protección por testigos

Comprobación de integridad MemChain AOF

Añada esta puerta de solo lectura a cada actualización y reinicio planificados. Su salida agregada es segura para automatización operativa.

bash

sudo aeronyx-server memchain verify-aof \
  --config /etc/aeronyx/server.toml

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

Resultado	Acción del operador
`status: verified` y `torn_tail_bytes: 0`	Continúe con validación de configuración y guarded restart.
`torn_tail_detected`	No edite el archivo. Solo guarded append-open puede retirar la cola física incompleta tras un scan semántico completo.
El comando devuelve error de integridad	Deténgase. Preserve AOF y logs; la corrupción semántica de un registro completo falla de forma cerrada.

Privacidad: Nunca suba, pegue ni publique el AOF. Comparta únicamente la salida agregada del verifier.

Límite completo de integridad y prueba: Registro firmado de compromisos y protección por testigos.

Mantenimiento controlado de caché de compilación Cargo

Las compilaciones repetidas pueden dejar decenas de GB de objetos Cargo regenerables. El comando unificado permite inspeccionar y recuperar espacio sin borrar estado del protocolo ni reiniciar el servicio.

1. Inspección sin cambiar el host

Ejecuta primero el inventario de solo lectura. Muestra el target antiguo, build root aislado, versión Rust fijada, SHA-256 del binario protegido y capacidad agregada del sistema de archivos.

bash

cd /root/open/AeroNyx
./deploy/node/aeronyx-node.sh build-cache --repo-dir "$PWD"

2. Vista previa de cada elemento eliminable

Revisa el dry-run línea por línea. La eliminación exige root y --yes explícito; status y upgrade nunca lanzan limpieza implícita.

bash

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

3. Ejecución de la limpieza confirmada

bash

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

Si usas un build root personalizado, exporta AERONYX_BUILD_TARGET_ROOT en los tres comandos para que inventario y limpieza resuelvan el mismo target aislado.

Ámbito protegido y eliminable

Protegido: Conserva target/release/aeronyx-server, la caché actual de toolchain/servicio, otros ejecutables release y artefactos rollback, datos de protocolo en /var/lib/aeronyx, identidad/configuración en /etc/aeronyx y cachés de otros servicios.
Regenerable: Solo elimina salidas Cargo regenerables: directorios debug/cross-target antiguos, deps, build, .fingerprint, incremental, .rlib, .rmeta, .d y targets de toolchains antiguos del mismo servicio.
Protección de ejecución: Antes de borrar obtiene el deployment lock compartido con install/upgrade y comprueba que MainPID ejecuta el binario protegido. Calcula su hash antes y después y falla si cambia.

Verificación posterior

La limpieza no reinicia el nodo ni requiere drenar sesiones activas. Después confirma service health, startup readiness, discovery quorum y frescura de la prueba de dos saltos.

bash

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

Evidencia de validación en producción — 26 de julio de 2026

Una ejecución controlada recuperó 50,649,768 KiB; el uso bajó de 90% a 65%. SHA-256, MainPID y reinicios no cambiaron; startup siguió sin fallos y la prueba de dos saltos permaneció ready/stable.

Límite de privacidad: El inventario muestra solo rutas locales, tamaños, versión de toolchain, hash del binario y capacidad agregada. No lee payloads cifrados, registros MemChain, claves, identidades peer, rutas, direcciones cliente, DNS, destinos ni grafo social.

Operación del cognitive worker opcional

El cognitive worker SuperNode es opcional y está deshabilitado por defecto. Actívelo solo en un nodo de proceso con un rol de confianza entendido.

Configuración mínima de proveedor 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 = []

También se admite api_key = "$ENV_VAR". No guarde secretos en configuración versionada.

Formas de endpoint compatibles con OpenAI

Las tres formas resuelven al mismo endpoint de Chat Completions:

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

Para type = "anthropic", api_base puede omitirse; el runtime actual usa el endpoint oficial Anthropic Messages.

Fallos y límites de recursos

Las respuestas correctas se limitan a 8 MiB antes de analizar JSON; los cuerpos de diagnóstico de error se limitan a 64 KiB.
Los fallos de transporte, API, parseo o respuesta vacía ponen al proveedor en un cooldown monotónico de 30 segundos en vez de deshabilitarlo para siempre.
HTTP 429 Retry-After se respeta entre 1 y 300 segundos; si falta, se usan 30 segundos.
El router puede usar otro proveedor sano y vuelve a considerar automáticamente al proveedor fallido al terminar el cooldown. No requiere tarea programada.

Antes de reiniciar, ejecute aeronyx-server validate -c /etc/aeronyx/server.toml. Este comportamiento está en el main actual; un nodo instalado debe recompilarse o actualizarse a una versión que lo incluya.

Límite de privacidad: los nodos de almacenamiento y relay siguen siendo node-blind. El cognitive worker habilitado y cualquier proveedor externo ven el prompt permitido por el nivel de privacidad. Mantenga default_level = "structured" y allow_full_for vacío sin consentimiento explícito para procesar contenido completo.