MemChain y almacenamiento cifrado

«MemChain y almacenamiento cifrado» 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 «MemChain y almacenamiento cifrado» 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 Nodeboard. 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.

Registro de compromisos y protección contra retrocesos

MemChain mantiene un registro append-only de compromisos para registros cifrados. Un bloque contiene compromisos de integridad y metadatos de orden, no memorias en texto claro ni claves de descifrado. Sirve para detectar manipulación y rollback; no es una blockchain pública ni afirma ofrecer consenso distribuido, finalidad o ejecución de tokens.

Antes de abrir UDP, TUN o la API pública, el coordinador verifica en orden el modo de durabilidad, toda la cadena persistida, el ancla local firmada de la punta, la evidencia de checkpoints guardada y los checkpoints firmados de nodos externos fijados por el operador.

Resultado verificado	Decisión de arranque
Coincidente	Continuar
Remoto atrasado	Continuar
Remoto adelantado	Detener: posible rollback local
Historial divergente	Detener: los historiales firmados entran en conflicto
Sin evidencia firmada	Continuar degradado solo sin strict; con strict, detener

Los testigos deben ser identidades Ed25519 fijadas explícitamente por el operador. Un peer permissionless no obtiene autoridad de arranque por aparecer en el peer store.

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.

El heartbeat solo informa del alcance, cantidad y requisito strict de los testigos; no transmite identidades, endpoints, hashes, firmas, contenido cifrado, propietarios ni relaciones sociales.

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

Cerebro propio y límite del proveedor de modelos

MemChain separa el almacenamiento ciego para el nodo del procesamiento cognitivo opcional. Activar un cognitive worker SuperNode no concede a los nodos de almacenamiento o relay permiso para leer la memoria.

Qué puede ver cada componente

Un nodo de almacenamiento o relay node-blind ve ciphertext, blind indexes, metadatos de ruta limitados y señales agregadas de salud; por defecto no recibe memoria en texto claro.
Un cognitive worker SuperNode habilitado recibe solo el payload permitido por su nivel structured, summary o full.
Un proveedor de modelos externo puede leer el prompt exacto que recibe. Use full solo con consentimiento explícito y un proveedor que el usuario u operador haya elegido confiar.
Un modelo local compatible con OpenAI mantiene la inferencia dentro del límite del operador, pero su worker sigue siendo un procesador de confianza, no un nodo de almacenamiento ciego.

Aislamiento en runtime

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.

Estos límites protegen la disponibilidad del nodo; no convierten la inferencia externa en cifrado E2E. El proveedor externo sigue siendo una decisión de confianza explícita y separada.