Descripción General de la Arquitectura PPN
La Red Privada PointSav (PPN) es el plano de infraestructura física del stack de PointSav. Es la capa responsable de: incorporar nodos físicos a una malla autenticada criptográficamente, gestionar los recursos de cómputo que esos nodos proporcionan, y alojar las máquinas virtuales que ejecutan Totebox Archives y pasarelas de orquestación. La PPN no es una capa de acceso a datos. No almacena datos. No toma decisiones de autenticación sobre quién puede leer un archivo. Gestiona la infraestructura física para que la capa de datos pueda ejecutarse sobre ella.
Las cuatro capas
La PPN y los sistemas construidos sobre ella se organizan en cuatro capas. Cada capa es ciega al estado interno de las capas por debajo y por encima de ella.
Capa del operador
La capa del operador es donde un administrador humano interactúa con la flota.
os-network-admin es la capa Foundation OS — el plano de control para la malla PPN. Se ejecuta en la máquina del operador (bare metal o contenedor LXC), gestiona la distribución del mapa de pares, y aplica las reglas del Diodo que restringen el flujo de comandos. No posee autoridad criptográfica: no puede leer datos de archivos, no puede aprobar el acceso a datos, y no puede emitir credenciales de identidad. Su rol es conocer qué nodos físicos están en la malla y hacer cumplir esa membresía — nada más.
app-network-admin es la interfaz del Terminal F8. Acepta la intención del operador en lenguaje natural en el puerto HTTP 8085, la enruta a través de service-slm para producir un comando binario de 16 bytes autorizado, y transmite ese comando por UDP en el puerto 9206 a la malla. os-network-admin en sí es un sondeador de aprobación de emparejamiento de unión de nodos aparte y minimalista — no tiene lógica propia de difusión de malla.
Ver: OS Network Admin, Protocolo de comandos PPN
Capa PPN
La capa PPN es el sustrato de transporte físico y de ceremonia.
La malla soberana es una superposición criptográfica WireGuard en una interfaz ppn0 dedicada. Cada nodo de la flota posee un par de claves a largo plazo; cada paquete se encripta antes de salir del nodo. Los comandos viajan como paquetes binarios de 16 bytes transmitidos simultáneamente a todos los pares de la malla; solo el nodo al que se dirige actúa.
service-ppn-pairing es el backend de ceremonia que gestiona las solicitudes de unión de nodos. Cuando un nuevo nodo físico quiere unirse a la malla, genera un código corto en base32 de Crockford; el operador ingresa este código y aprueba la solicitud de unión. El protocolo está diseñado para actualizar este intercambio a un CPace PAKE (RFC 9382) con comparación de Cadena Corta Autenticada (SAS) para cerrar la brecha de intermediario; la capa PAKE/SAS está especificada pero aún no implementada — el servidor service-ppn-pairing actual realiza búsqueda de código corto más aprobación del operador. El nodo aprobado se escribe en el registro de solo adición nodes.jsonl.
El Protocolo Génesis gobierna el primer arranque: un nodo genera su par de claves a partir de entropía de hardware, entra en un patrón de espera sellado, y aguarda una reclamación administrativa — sin ninguna preconfiguración ni dependencia del plano de control.
Capa de hipervisor
La capa de hipervisor es el sustrato de cómputo.
os-infrastructure es la capa de hipervisor planificada, prevista para alojar las máquinas virtuales que ejecutan Totebox Archives y pasarelas de orquestación (QEMU/KVM para empezar; un hipervisor de metal desnudo de Tipo I bajo NetBSD/NVMM en la Fase 2, seL4/Microkit en la Fase 3). Está diseñada para gestionar un pool de recursos por nodo — memoria mediante virtio_balloon, CPU mediante cpu.weight de cgroups v2 por proceso QEMU — pero ningún mecanismo está construido todavía: el código real de os-infrastructure es un stub Multiboot2 de metal desnudo con salida de texto por framebuffer y un handshake mDNS de génesis, sin lógica de pooling de recursos. os-orchestration, descrito en otra parte de este artículo como un agregador sin estado, es igualmente un scaffold de 2 líneas hoy, no un sistema en funcionamiento.
El pool está acotado al nodo físico. La colocación de cargas de trabajo entre nodos es responsabilidad de la capa de Orquestación de Totebox; una vez que una VM se coloca en un nodo, el hipervisor gestiona su asignación de recursos local.
Ver: Pool de Recursos del Hipervisor PPN
La extensión distribuida planificada de esta capa tiene como objetivo permitir que las VMs tomen prestado cómputo de otros nodos físicos a través de la malla WireGuard — usando bloques de memoria de conexión en caliente mediante virtio-mem, coordinados por un ledger de capacidades distribuido en moonshot-protocol. El préstamo de memoria entre nodos, el controlador automático de balloon y un planificador de VMs entre nodos son hitos planificados; solo el pool por nodo está implementado hoy.
Ver también: Tejido VM Distribuido PPN
Capa de Orquestación de Totebox
La capa de Orquestación de Totebox es el plano de datos. Se ejecuta dentro de las VMs gestionadas por el hipervisor y está completamente separada de la PPN.
Los Totebox Archives (cluster-totebox-*) son bóvedas de datos soberanas — ledgers WORM inmutables empaquetados como imágenes de disco de arranque libremente transferibles. Cada archivo posee un par de claves Ed25519 registrado en pairings.yaml. Está diseñado para exponer datos solo mediante objetos de capacidad firmados, entregados a través de un protocolo basado en capacidades — el diseño previsto para ese protocolo se describe en Totebox Archive; hoy no hay un nombre de protocolo específico incorporado al código.
os-console es el terminal de operador nativo de teclado. Se conecta a un archivo a la vez (o a varios mediante os-orchestration) y es el nivel gratuito.
os-orchestration es un agregador sin estado para múltiples archivos. Está diseñado para distribuir consultas basadas en capacidades a través de muchos archivos simultáneamente, devolviendo solo filas de resultados (nunca registros brutos), y para no poseer claves propias. Es el nivel de pago: la agregación de múltiples archivos es el límite comercial.
Ver: Totebox Archive, os-orchestration — El agregador de flota
Tres propiedades clave
Invariante de aislamiento
El hipervisor no tiene capacidad de lectura sobre el estado interno de la VM. Sabe que una VM está consumiendo N páginas de RAM y Y por ciento de vCPU. No sabe si la VM está ejecutando os-totebox, os-orchestration o cualquier otra cosa. El Totebox Archive dentro de la VM no sabe nada sobre la inflación del balloon, los pesos de cgroup, ni en qué nodo físico se encuentra.
Esto significa que una vulnerabilidad en la capa de enrutamiento — la PPN — no proporciona acceso al contenido de los archivos. Los dos planos son estructuralmente ciegos entre sí.
Archivos libremente transferibles
Debido a que el hipervisor gestiona solo el ciclo de vida de la VM y la asignación de recursos — no los datos dentro de las VMs — un Totebox Archive puede detenerse, copiarse la imagen de disco a cualquier otro nodo PPN, y reiniciarse allí sin ningún cambio en sus datos ni en su identidad. El pool del nodo destino absorbe la carga de trabajo. El historial, las claves y el estado del archivo permanecen sin cambios.
La imagen de disco es el archivo. El pool de recursos es la infraestructura del nodo. Mover la imagen mueve el archivo.
Autoridad criptográfica nula en el plano de red
os-network-admin y la malla PPN no llevan autoridad criptográfica sobre los datos de los archivos. Enrutar un nodo a la malla no concede ningún acceso a datos. Eliminar un nodo de la malla no revoca ningún acceso a datos. El acceso a datos está gobernado completamente por pairings.yaml y el sistema de par de claves MBA — un plano separado sin conexión con la PPN.
Esta separación es intencional: el plano de control de red y el plano de acceso a datos están diseñados de modo que un fallo o vulnerabilidad en uno no se propague al otro.
Lo que la PPN no es
- No es una capa de acceso a datos. La PPN gestiona nodos físicos. El acceso a los datos de los archivos se realiza a través de
os-consoleuos-orchestrationmediante consultas autenticadas por MBA — no a través de WireGuard. - No es un planificador de cómputo.
os-network-adminno planifica cargas de trabajo entre nodos. La colocación entre nodos es responsabilidad degateway-orchestration-command-1(capa de Orquestación de Totebox). El hipervisor gestiona el pool de recursos local después de la colocación. - No es una autoridad de identidad. La malla PPN sabe qué nodos físicos están inscritos. No sabe qué operadores están autorizados para leer qué archivos. Eso corresponde a
pairings.yaml.
Temas relacionados
- Malla Soberana — superposición WireGuard, protocolo de comandos binarios de 16 bytes, topología hub-spoke
- Protocolo Génesis — secuencia de arranque autónomo en primer arranque, ensamblaje de flota diferido
- Protocolo de comandos PPN — el formato de cable binario de 16 bytes transmitido por UDP en el puerto 9206
- service-pointsav-link — adaptador de flota PointSav planificado — adaptador conectable en caliente que conecta nodos os-* a la flota
- OS Network Admin — capa Foundation OS, autoridad criptográfica nula, ceremonia de unión de nodos
- Pool de Recursos del Hipervisor PPN — virtio_balloon por nodo + planificación de vCPU
- Totebox Archive — bóveda de datos WORM soberana, imagen de disco libremente transferible
- os-orchestration — El agregador de flota — agregador sin estado de múltiples archivos, nivel de pago
- Tejido VM Distribuido PPN — tejido VM entre nodos planificado: préstamo virtio-mem, ledger de capacidades distribuido, atestación soberana
- Cómo inscribir un nodo PPN — guía paso a paso: registrar un nodo de cómputo con el controlador de flota y verificar el primer latido
- Añadir un nodo a una flota en funcionamiento — guía paso a paso: inscribir un segundo nodo en una flota en funcionamiento sin interrumpir las operaciones existentes
Cite this record: /wiki/ppn-architecture-overview — revision b7f09af0, last updated 23 June 2026.