Registro firmado de compromisos y protección por testigos

AeroNyx opera un registro firmado y append-only de compromisos para registros MemChain cifrados. Demuestra orden e integridad, pero la infraestructura no puede leer la memoria. No es una blockchain pública.

Invariante del protocolo: Coordinador, followers, testigos, backend y web solo procesan compromisos de texto cifrado y evidencia operativa limitada; nunca reciben memoria en claro, claves, relaciones de propietarios ni grafo social.

Arquitectura actual de producción

Se usa un coordinador y tres nodos follower/testigo auditados. El arranque requiere 2 de 3 checkpoints firmados y la producción en ejecución exige un lease corto 3/3.

observed_at=2026-07-16 · reporting_nodes=4 · coordinator=1 · followers=3 · height=33 · commitments=8,339 · witness_lease=3/3.

client.encrypt_and_sign
  -> coordinator.append_opaque_commitment
  -> follower.verify_signed_ancestry
  -> pinned_witness.retain_checkpoint_and_grant_bounded_lease

Flujo de escritura y verificación

1. El cliente cifra y firma localmente un registro de memoria elegible.
2. El coordinador añade únicamente el compromiso opaco y los metadata de orden.
3. Cada append verifica el Block firmado anterior y actualiza un high-water anchor local firmado.
4. Los followers obtienen páginas limitadas, verifican ancestry y firmas y conservan certificados de checkpoint.
5. Solo se crea un nuevo commitment Block mientras todos los runtime witnesses configurados conceden la misma instancia de lease corto.

Control de inicio y runtime

Se usan dos controles independientes para detectar rollback y evitar que coordinadores copiados produzcan al mismo tiempo.

• Umbral de inicio: Antes de abrir listeners UDP, TUN o API se necesitan pruebas firmadas válidas de al menos dos witnesses distintos de los tres fijados por el operador.
• Lease de runtime: Los tres witnesses configurados deben conceder un lease corto al coordinador activo. Una renovación parcial queda degraded y la producción nueva se detiene al expirar la autoridad.
• Recuperación: Cuando vuelve la conectividad, una ronda completa de lease restaura la autoridad de producción e incrementa el contador agregado de recuperaciones.

Comportamiento ante fallos

Una renovación parcial se marca como degradada y reintenta mientras el lease vigente sea válido. Al expirar, se detiene la producción de nuevos compromisos. Un estado remoto por delante o historias firmadas divergentes bloquean el arranque.

renewal_degraded -> retry_until_expiry

expired -> coordinator_lease_production_permitted=false

remote_ahead | diverged -> startup_denied

Observabilidad pública

La API expone solo agregados: nodos verificados, altura tip, compromisos y estado del lease. No expone hashes, firmas, identidades de testigos, endpoints, propietarios ni contenido.

GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/
data.protocol_status.memory_chain

{
  "mode": "signed_commitment_ledger",
  "status": "witness_protected",
  "verified_nodes": 4,
  "coordinator_nodes": 1,
  "follower_nodes": 3,
  "max_verified_tip_height": 33,
  "max_verified_commitment_count": 8339,
  "max_granted_witnesses": 3,
  "max_required_witnesses": 3,
  "network_consensus": "not_claimed"
}

Coordinador, followers, testigos, backend y web solo procesan compromisos de texto cifrado y evidencia operativa limitada; nunca reciben memoria en claro, claves, relaciones de propietarios ni grafo social.

Límite de privacidad

El contrato central y público excluye record IDs, Block hashes, firmas, identidad de witnesses, endpoints, owners, cuerpos ciphertext, plaintext, rutas, client metadata, wallet-level traffic y aristas del social graph. El conteo agregado de commitments demuestra trabajo del sistema, no qué dice una memoria ni quién la creó.

Lo que no es

• No es consenso permissionless, finalidad bizantina ni fork choice.
• No es un registro de tokens ni una plataforma de contratos inteligentes.
• No permite que los nodos lean memoria en claro.

Heartbeat

coordinator_lease_state, coordinator_lease_granted_witnesses, coordinator_lease_required_witnesses, coordinator_lease_seconds_remaining, coordinator_lease_production_permitted, coordinator_lease_last_failure_at, coordinator_lease_consecutive_failures, coordinator_lease_recoveries_total.

Preguntas frecuentes

¿AeroNyx tiene Blocks ahora?

Sí. El subsistema de compromisos usa Blocks firmados para ordenar compromisos opacos de registros cifrados. No debe describirse como blockchain pública ni como red de consenso global.

¿Qué sucede si un witness está desconectado?

La renovación parcial aparece como degraded mientras la autoridad vigente sea válida. Si el lease expira sin una nueva concesión de todos los witnesses, la producción de compromisos nuevos se detiene automáticamente.

¿Puede un witness leer la memoria MemChain?

No. Verifica la estructura de compromisos firmados y la titularidad del lease; no recibe registros en claro ni claves de descifrado.

Documentación relacionada: MemChain and Decentralized Node Operations.

Verificar el historial local de solo anexado

Cada nodo descentralizado AeroNyx actual puede inspeccionar su archivo append-only local de MemChain sin mostrar contenido de memoria. Es una puerta de integridad local para reinicios, actualizaciones, recuperación mirror e investigación de incidentes.

Qué verifica

• Framing canónico y limitado, con un máximo de 10 MiB por registro decodificado.
• Cada Fact independiente y cada Fact dentro de un Block coincide con su fact_id derivado del contenido.
• El Merkle root de cada Block coincide con el orden exacto de identificadores Fact almacenados.
• Los Block consecutivos conservan la continuidad de height y del previous-Block hash.
• El archivo termina en un límite de registro completo; una cola física incompleta se informa por separado.

Comando de solo lectura

Ejecútelo sobre la ruta configurada o indique una ruta explícita:

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

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

Puerta de actualización y recuperación

1. Ejecute verify-aof antes de sustituir el binary y conserve el resultado agregado en el command audit.
2. Valide el nuevo binary y ejecute el mismo scan de solo lectura antes de reiniciar el servicio.
3. Tras reiniciar, confirme que replay restauró la misma o una height superior y ejecute los health checks.
4. Si un registro completo falla la validación semántica, deténgase y preserve la evidencia; no trunque ni fusione automáticamente.

Límite de la prueba

El comando solo muestra la ruta y conteos agregados. Nunca muestra valores Fact, record ID, Block hash, firmas, propietarios, identidad de witnesses, endpoints, rutas ni claves. Un Mirror o Full node puede validar independientemente los mismos bytes locales tras sincronizar sin conocer el contenido cifrado.

Este scan no sustituye validación de firmas Block, witness certificates, runtime leases, fork choice ni consensus. Un AOF limpio prueba integridad estructural local, no que todos los participantes sean honestos.

Rutas de implementación:

• crates/aeronyx-server/src/services/memchain/aof.rs
• crates/aeronyx-server/src/main.rs